Re: [RFC] pre-c89 in libltdl

[Simon Josefsson]

Gary V.Vaughan <address@hidden> writes, in an old thread:

> On 1 Apr 2004, at 00:41, Bob Friesenhahn wrote:
>> On Thu, 1 Apr 2004, Gary V.Vaughan wrote:
>>> On 31 Mar 2004, at 17:47, Bob Friesenhahn wrote:
>>>> Libltdl itself is not thread safe.
>>>
>>> That's a bug!  Do you have any test cases? (I have never programmed
>>> with threads, so it is entirely possible that the mutex code I added
>>> is incredibly naive).
>>
>> Actually, libltdl is documented as being thread unsafe.  It offers a
>> way to use user-supplied locking functions so it could become thread
>> safe.  Unfortunately, the definitions for these user-supplied locking
>> functions don't match what is available from POSIX threads (the
>> locking must be re-entrant on a per-thread level) so it is not as
>> easily used as it could be.
>
> I see :-(
>
> If you were to write a threaddemo typical of how a threaded client might
> use libltdl, I would be happy to fix libltdl to work with it (after the
> next release).

Could someone explain exactly why libltdl is thread unsafe, e.g. what
it need these locking functions for, in the first place?

I'm considering using libltdl's dlopen generalization in GNU SASL to
have it load each SASL mechanism dynamically instead of it having to
be part of the main libgsasl.so, but I believe libgsasl.so is in no
position to know or make demands on what thread environment the
application uses.  How do other library developers handle this
problem?  I'd very much like to avoid everything about threads, in my
code for the library, that I can, but still be compatible with
threaded applications.

Thanks for any ideas.