Re: Allowing user data in lt_dlhandles (revisited)

[Alexandre Oliva]

On Jan  5, 2001, "Gary V. Vaughan" <address@hidden> wrote:

> The attached patch implements association of user data with lt_dlhandles
> in a way that doesn't suffer from the problems inherant in Thomas'
> patch from last year (i.e. several libraries that share libltdl.la
> can independantly manage their own lt_dlhandle related data without
> conflict).

I'm a little bit worried about multi-thread safety.  I'll grant that
lt_dlopen itself isn't MT-safe, so it's up to the caller to ensure
thread safety.

> +     (rpl_memcpy): A minimal fallback implementation.
> +     (rpl_realloc): A realloc implemented with lt_dlmalloc and
> +     lt_dlfree.

rpl?  Ah, replacement!

Methinks we could supply a lt_dlrealloc variable, to be replaced by
the user in case s/he wants to improve realloc performance.  It would
be rpl_realloc by default, and rpl_realloc could use realloc() if
lt_dlmalloc == malloc and lt_dlfree == free.  And, in fact, it might
use lt_dlrealloc only in case it would have called realloc(), so that
we save users from having to duplicate all the logic of free/malloc in
realloc.

Also, if size == 0, rpl_realloc() should free() the given memory area,
as long as it is non-NULL.


WRT _set_data, I'd rather let it return a pre-existing data item,
instead of forcing get/remove/set sequences in cases of changing the
pointer.  OTOH, maybe you shouldn't be changing it very often...  I
have mixed feelings about that.  But I suppose you've put more thought
into this than myself, so it's probably ok.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  address@hidden, redhat.com}
CS PhD student at IC-Unicamp        address@hidden, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me