Realised I’m still using malloc in the add-onlys.
Looking at add-only hash now. It has a table of add-only unbalanced btrees – in other words, it does a lot behind the scenes. At things stand, all those allocs will have to be performed by the user – the hash state, the table of btree states, and I’ll have to expose the hash internal compare/delete functions to the user, so he can use them in the btree init. Ugly.
Maybe I should consider some kind of malloc callback where the library can indicate which NUMA node it wants to be on…
Comments are closed.