[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 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
- Allowing user data in lt_dlhandles (revisited), Gary V. Vaughan, 2001/01/04
- Re: Allowing user data in lt_dlhandles (revisited),
Alexandre Oliva <=
- Re: Allowing user data in lt_dlhandles (revisited), Gary V. Vaughan, 2001/01/05
- Re: Allowing user data in lt_dlhandles (revisited), Alexandre Oliva, 2001/01/05
- 1.4 release schedule [Was Re: Allowing user data in lt_dlhandles (revisited)], Gary V. Vaughan, 2001/01/05
- Re: 1.4 release schedule [Was Re: Allowing user data in lt_dlhandles (revisited)], Alexandre Oliva, 2001/01/06
- Re: 1.4 release schedule [Was Re: Allowing user data in lt_dlhandles (revisited)], Gary V. Vaughan, 2001/01/07
- Re: 1.4 release schedule [Was Re: Allowing user data in lt_dlhandles (revisited)], Alexandre Oliva, 2001/01/08
- Re: 1.4 release schedule [Was Re: Allowing user data in lt_dlhandles (revisited)], Gary V. Vaughan, 2001/01/08
- Re: 1.4 release schedule [Was Re: Allowing user data in lt_dlhandles (revisited)], Ossama Othman, 2001/01/08
- Re: 1.4 release schedule [Was Re: Allowing user data in lt_dlhandles (revisited)], Alexandre Oliva, 2001/01/08