Re: (ITS#6437) sl_malloc issues

[h.b.furuseth@usit.uio.no]

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.

-- 
Hallvard