hyc@symas.com writes:

h.b.furuseth@usit.uio.no wrote: Go ahead and commit. In working pieces if necessary. We'll pick and choose...

Committed one batch of fixes/tweaks, hopefully independent after the first one or two. Next batch will have to walk all over some of these.

...

• Why is there a slap_sl_mem_detach() when there is no way to reattach it? As far as I can tell all the caller can do is to inspect/clean up the returned slab_heap itself.

It was originally implemented in 2.2 to support psearch for sync replication. It was obsoleted when the syncprov overlay was written in 2.3, we just never deleted it. Go ahead and delete it.

Actually I just realized the context can be used thread-less just fine, even if it's only relevant if any 3rd party modules do it. Might as well keep it in RE24, just in case. But I'll move structs slap_object and slap_heap back to sl_malloc.c, so such modules cannot mess with them.

(And remember, the point of sl_malloc is that a heap here doesn't need any special cleanup - just free it and forget it.)

Not quite, due to the ch_malloc fallbacks. Anyway, I've committed some comments with my understanding of the package.

...

• Some failures assert(0)/exit() like ch_malloc.c, but without giving a Debug() message first.

don't really care...

I do, I've had silent exits from slapd before and hated it.