Re: [RFC] pre-c89 in libltdl

[Simon Josefsson]

Bob Friesenhahn <address@hidden> writes:

>> So my preferred approach would be to only enable the use of libltdl if
>> I know it would be thread safe.
>
> Since you have no way of knowing if libltdl or dlopen, dlerror, dlsym,
> dlclose, will be thread safe and you are not willing to add locks to
> ensure thread safety, then it sounds like you shouldn't be using
> loadable modules. :-)

I'm coming to that conclusion too.  But what if libltdl (perhaps as
part of its autoconfery) could tell me if dlopen (or whatever system
interface libltdl uses) was thread safe or not?  Having it do that
would be useful, even if it would only indicate thread safety on Linux
or HURD.  (Assuming those dlopen's are thread safe...)

> The easiest solution is usually to use POSIX thread locking and then
> tell users they will need to add -lpthread in order to use your
> library.

This is too painful for me.  If I did this, I'm convinced someone will
report a situation in which linking with libpthread breaks something
else in some non-trivial way.  If there isn't an easier option, I
think I'll wait with loadable modules until things mature.

>> 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
>
> It will take about 7 years before any ratified POSIX standard is in
> common-enough use that you can rely on it.  If the OS is Linux, then
> you may need to wait longer (witness how long POSIX.4 APIs are taking
> to get implemented).

But checking if that particular POSIX standard is supported shouldn't
be difficult (I'm assuming the POSIX standard has some useful CPP
symbols to check on).

I think I found the POSIX text for dlopen, but it doesn't say a word
about threads that I can see.  That's probably bad...  Sigh.

Perhaps this leads to a wish-list for HURD: a documented known
thread-safe replacement for dlopen.

Thanks,
Simon