Re: [RFC] pre-c89 in libltdl

[Simon Josefsson]

Bob Friesenhahn <address@hidden> writes:

> On Thu, 15 Apr 2004, Simon Josefsson wrote:
>
>> Could someone explain exactly why libltdl is thread unsafe, e.g. what
>> it need these locking functions for, in the first place?
>
> Libltdl maintains its own internal data structures in order to
> maintain the list of modules which are loaded and to cache some
> information it has learned.

It is impossible to re-write this code in a thread-safe way?

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

What I'm after is this: if the system has a dlopen (or similar) that
my library can use, that doesn't create problems for any application
that uses my library (e.g., thread unsafety), I want to enable
building my packages as modules, and use ltdl to do the dlopen'ing.
If the system doesn't have a (for me) usable dlopen (or similar),
don't even bother building modules, but build everything into a big
shared library.

>> Could someone explain exactly why libltdl is thread unsafe, e.g. what
>> it need these locking functions for, in the first place?
>
> I should mention that lazy symbol resolution could potentially cause
> problems in a mutithreaded application since if a symbol is accessed
> which was not already accessed, then the run-time linker will execute
> code to resolve that symbol.  It may be that the complete application
> blocks while the symbol is resolved, or perhaps some threads continue
> executing on a different CPU.  Whether this is an issue is
> system-dependent.

Are you talking about the symbol resolver in the system, or in
libltdl?  I'm assuming the latter, but I'm not sure I follow how the
thread safety then is system specific; isn't it up to the libltdl code
to make sure it wouldn't be a problem (assuming the application
specify the proper locking functions)?

If this was about the system symbol resolver, for just any shared
library (not dlopen), then if that resolving is thread unsafe, I have
a big problem.  Aren't there any standards that say shared library
symbol resolving must be thread safe?

I should have read the libltdl code before my last post, but I have
read it now, and I see the locks are used in many places, and it
doesn't look trivial to remove them.  Hm...

Thanks,
Simon