libtool-patches
[Top][All Lists]
Advanced

[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 08:10:29 -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:

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

We should probably export mutex lock/unlock pointers-to-functions, so
that an application uses a single lock/unlock mechanism for libltdl.
Think of multiple clients within a single multi-threaded application,
each one using a different mutex to control access to libltdl.  This
is certainly not going to work.

Now, if we provide means for people to register lock/unlock functions,
and macros that call them if they're non-NULL, we can guarantee
everything operation will be atomic.  Or, even better: we can call
these functions ourselves, so that callers don't have to worry about
that.

If we require such locks to be reentrant, we'd even be able to have
multi-operation transactions (such as removing one entry from the
keyed data of a certain library and adding it to another library's,
while holding the mutex).  But I don't think we have to go as far as
requiring reentrant mutexes: whoever needs them should be able to
provide one such lock/unlock primitive.

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

Yep.  That's why, at the end, I suggested that we always called
rpl_realloc(), that would call lt_dlrealloc (or realloc(), if
lt_dlrealloc is NULL and lt_dlmalloc == malloc and lt_dlfree == free)
only in the portable cases.  If lt_dlrealloc is NULL but lt_dlmalloc
or lt_dlfree have been modified, we'd not use realloc(), but implement
it in terms of lt_dlfree() and lt_dlmalloc().  How does that sound?

> trash the contents of the original pointer if there is not enough
> memory to create a new one).

Really?  Ouch!  That's a good reason to never use realloc().

> Also, I didn't want to force the user to maintain an lt_dlrealloc
> function pointer by default.

I don't want to force that, only to provide means for the user to
supply an implementation that wouldn't have to deal with all the
special cases.

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

Portability regarding behavior regarding NULL pointers and zero sizes,
IIRC.

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



reply via email to

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