Thread-safety "guidelines" of LTDL

[Andreas Mohr]

Hello,

I've been reading "Using libltdl in a multi threaded environment" at
http://www.gnu.org/software/libtool/manual/html_node/Thread-Safety-in-libltdl.html#Thread-Safety-in-libltdl

and I must say I feel that it's rather misguided.

I'm as threading-resistant as anyone *)
, but IMHO suggesting the use of ugly, contention-hampered,
__insufficient__ mutexes to make LTDL "thread-safe" in an external manner
is too short-sighted.

With a bigger application, one might happen to load several OEM
libraries which each may make use of LTDL (i.e., one single, shared
LTDL library instance).
And those will NOT have any coordination between their use of the LTDL API,
IOW there will NOT be a common mutex used by all disparate
LTDL users (possibly threaded, additionally) --> chaos and despair.

IMHO it would be a MUCH better idea to provide properly initialized,
_separate_ "user sessions" of LTDL, by discouraging use of
static-data-hampered lt_dlinit()
and instead adding a new lt_dlinit_session() which returns an malloc'd
per-session opaque *handle* that would then be closed via lt_dlexit_session().

This handle would then manage all formerly data-segment-static content
(such as ltdl.c's user_search_path, handles, initialized etc.
variables), to provide proper per-_user_ isolation of LTDL internals.

The old, non-thread-supporting lt_dlinit()/lt_dlexit() APIs
could be changed to simply allocate into one static handle
(i.e., allocate one static user session), via
lt_dlinit_session().

It's all a matter of proper object-oriented encapsulation.
Since one entire process space makes use of a single instance of the LTDL 
library,
it's LTDL itself which needs to make sure that all users within that process
have their very own management space (and that's not even purely a
multi-threading issue - one could argue in general
that having search dirs tweaked by multiple _unrelated_ participants
isn't such a good idea either).

This conversion of course unfortunately would mean that one would have to pass
the session handle as the first argument to lt_dlopen() etc.
(and the old non-per-session lt_dlopen() would internally invoke sessioned
lt_dlopen() with its static session handle).

Of course this rework of LTDL to provide sessions would bloat its code
by a significant percentage (maybe 30%?), but IMHO LTDL not providing
proper per-session isolation by default is a problem that it should never have 
had.

As it stands, LTDL is potentially unsuitable for multi-usage
applications, and much more so for heavily multi-threaded apps.

Its platform abstraction is a very nice thing to have, though.

Thanks,

Andreas Mohr

*)
in fact I would say that threading is an architecture-disrupting "feature"
which in many cases shouldn't be allowed near critical systems;
UNIX has been strongly working towards providing powerful, _fast_ IPC
and perfectly isolated processes, as opposed to a certain Other Platform
which had to invent all sorts of thread-based workarounds (even fibers
etc.) due to the fact that it ha{s|d} abysmally weak IPC capabilities
and was process creation challenged.