[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Allowing user data in lt_dlhandles (revisited)

From: Alexandre Oliva
Subject: Re: Allowing user data in lt_dlhandles (revisited)
Date: 05 Jan 2001 01:43:42 -0200
User-agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands)

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
> 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

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
Red Hat GCC Developer                  address@hidden,}
CS PhD student at IC-Unicamp        address@hidden,}
Free Software Evangelist    *Please* write to mailing lists, not to me

reply via email to

[Prev in Thread] Current Thread [Next in Thread]