[Date Prev][Date Next]
Re: (ITS#6437) sl_malloc issues
> firstname.lastname@example.org 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.