[email protected] writes: > [email protected] 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. -- Hallvard
