Re: [RFC] pre-c89 in libltdl

[Simon Josefsson]

Bob Friesenhahn <address@hidden> writes:

>> > In addition to this, the systems's dlopen() (or equivalent) is
>> > possibly not thread safe.
>>
>> Bummer.  Would a mode of operation that enabled ltdl only in case it
>> can operate thread safely be possible?  Is the POSIX dlopen thread
>> safe?  If so, that's probably good enough for my users.
>
> Does POSIX specify dlopen now?

My man page says "POSIX 1003.1‐2003 describes dlclose, dlerror,
dlopen, dlsym".

> The easiest solution is to ignore libltdl's own locking mechanism and
> protect calls to libltdl's functions with your own global lock.
> Modules are not loaded very often, and module loading is usually
> pretty quick, so there is not much value from fine-grained locking in
> libltdl.

My problem is that my library doesn't have any locking mechanism, as
it is re-entrant and pure C89.  I could add hooks to let the
application specify the locking mechanism it uses, but I'm hesitating
about this as it leads to much more complex maintenance, especially
since my library is typically used by other libraries, and not by
applications directly.  (Compare the recent discussions for a locking
mechanism in libgcrypt.)

So my preferred approach would be to only enable the use of libltdl if
I know it would be thread safe.

Perhaps I shouldn't be using libltdl?  If POSIX says dlopen is thread
safe (I have to read up on that), I could check for a POSIX dlopen and
only use modules if the system has POSIX dlopen.  Alas, if say
shl_load on HP-UX is thread safe (I dunno, but for the sake of
discussion assume it is), I would miss out on modules on HP-UX.  So
then it would be useful if something like libltdl existed, but that it
would only work across those dlopen implementations that were thread
safe (and refuse to work if that wasn't the case).

Thanks,
Simon