Re: Allowing user data in lt_dlhandles (revisited)

[Gary V. Vaughan]

On Fri, Jan 05, 2001 at 01:43:42AM -0200, Alexandre Oliva wrote:
> 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.

Interesting you mention that... the stuff I am folding into ltdl at
the moment is to allow me to do a clean reimplementation of gmodule
(from glib/gtk+) in time for glib-2.0.  gmodule *is* thread safe, but
only becaus it does mutex locking around the body of most of it's
calls.  If this can all work, I think we are okay...

> > +   (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.

I didn't do this because I wanted to be able to rely on the particular
semantics I have implemented (some vendor reallocs behave unexpectedly
when passed a NULL pointer or a 0 size, or trash the contents of the
original pointer if there is not enough memory to create a new one).
Also, I didn't want to force the user to maintain an lt_dlrealloc
function pointer by default.  I don't want to export a lt_dlrealloc
pointer, incase the user points it at one of the vendor's broken
reallocs.  There are few enough call's to it, that I'm not worried
about the small hit in efficiency anyway.

Can you refresh my memory over what your concern's with realloc were,
from the last time I submitted a patch to add `lt_dlrealloc =
realloc'?

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

Okay.

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

I think you are right.  That allows me to remove _remove_data frm the
API (in favour of ``free (_set_data (key, handle, NULL)'', and it
actually allows me to write a faster _set_data implementation when
replacing the data for an existing key.  Thanks!

Since I already have an okay, this is an FYI.

Cheers,
        Gary.
-- 
  ___              _   ___   __              _         mailto: address@hidden
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___       address@hidden 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/                      /___/                  gpg public key:
http://www.oranda.demon.co.uk           http://www.oranda.demon.co.uk/key.asc

2001-01-05-dlcaller.patch
Description: Text document