RE: Thread-local malloc discussion summary

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: Luke Howard [mailto:lukeh@PADL.COM]

> >I've modified ch_free (and ch_realloc) to test the pointer
> argument and pass
> >it off to sl_free (and sl_realloc) if necessary. This gives
> some freedom from
> >mismatch problems, and with the new
> ldap_pvt_thread_pool_context() function
> >this solution doesn't cost much. So I'm going to revert the
> SLAPI filter
> >patches to slapd/search.c, I think it should be safe.

> So, my plugin resets the filter to one that is
> slapi_ch_malloc()'d, this
> is set to op->ors_filter in doSearchRewriteFNs(), and eventually this
> filter is freed with filter_free_x().

> filter_free_x() then calls op->o_tmpfree(), on memory that has been
> allocated using ch_malloc()... things will blow up, surely?

No, it's safe because sl_free also tests the pointer and passes it off to
ch_free if it doesn't own the memory. There are some cycles here, but no
infinite recursions... It would be nice if this could all be put into one
place, to avoid the mess of cyclic dependencies, but I don't see how at the
moment:
	slapd/ch_malloc(size) -> liblber/ber_memalloc_x(size, NULL)

	liblber/ber_memalloc_x(size, ctx) -> slapd/sl_malloc(size, ctx)

if sl_malloc runs out of memory:
	slapd/sl_malloc(size, ctx) -> slapd/ch_malloc(size)

I think ideally sl_malloc would just be part of liblber/memory.c but we can't
do it this way because sl_malloc depends on libldap_r.

> You could make slapi_ch_malloc() use sl_malloc().

I thought about that. This would be great, but it assumes that plugins only
want temporary memory, and will never want to malloc something that persists
beyond the current operation. I don't think we know enough about how people
use their plugins to be able to make that assumption.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support