libtool-patches
[Top][All Lists]
Advanced

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

Re: [RFC] pre-c89 in libltdl


From: Alexandre Oliva
Subject: Re: [RFC] pre-c89 in libltdl
Date: 20 Apr 2004 04:09:51 -0300
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

On Apr 19, 2004, "Gary V.Vaughan" <address@hidden> wrote:

> On 15 Apr 2004, at 23:05, Howard Chu wrote:
>>> Some systems will supply an alternate C library, or other libraries if
>>> the application is built to be thread safe.
>> 
>>> There is no free lunch when it comes to thread safety.
>> 
>> Sounds to me like libltdl should completely ignore the
>> issue. Applications
>> should assume that the native dlopen is NOT thread-safe, and take
>> care of
>> locking themselves. All application calls into libltdl should thus be
>> protected by the caller.

> Agreed.

> As I am on a libltdl code simplification fix, a patch to drop MUTEX
> fluff
> entirely will be on its way shortly...

Actually...  I don't think this is a good idea.

According to the POSIX standards, all of the dl* functions are
supposed to be thread safe.  However, not all implementations are, so
it's nice that libltdl makes it easier to get POSIX-like behavior out
of non-POSIX implementations.

Leaving mutexes up to the caller means that an app that links with
multiple libraries that each wants to ltdlopen other stuff, odds are
that the libs are all going to have to be modified to use a single
mutex.  Remember that if each caller uses its own mutex, each one
protects itself from itself only, not from other potential callers.
When libltdl offers mechanisms to register the mutex function, even if
it's re-registered multiple times, there's still a single mutex for
all operations (unless there's an ongoing operation while the mutex
functions are replaced; ugh!), so it's an overall win.

Of course, we don't have to handle these problems ourselves, but I
think it's nice that we do.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   address@hidden, gcc.gnu.org}
Free Software Evangelist  address@hidden, gnu.org}




reply via email to

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