Re: [RFC] pre-c89 in libltdl

[Bob Friesenhahn]

On Thu, 15 Apr 2004, Simon Josefsson wrote:

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

The only way to write code which is thread safe without locks is to
make it completely re-entrant.  That means that it would not be
allowed to store any data which lives longer than the call.  This
would limit libltdl's usefulness.  For example, if the code attempts
to load a module which is already loaded, or is in the process of
being loaded, libltdl would have no way of knowing so it would attempt
to load the module again.

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

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.

> > 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)?

The symbol resolution is provided by the "system" but usually executes
from within the context of the process.  The reason for this is that
most programs only require a few symbols from the shared library, so
it is more efficient to load symbols as they are demanded.  Hopefully
no current systems suffer from the situation I described.

Bob
======================================
Bob Friesenhahn
address@hidden
http://www.simplesystems.org/users/bfriesen