Doug Rabson wrote:
> Now I'm really confused. I can't see how this can work properly. Imagine
> the following scenario:
>
> An application 'base' is linked against libc and is not threaded. This
> application loads a plugin 'Xplug.so' via dlopen(). Xplug doesn't use
> threads but it does link against libX11.so which calls pthread_mutex_*
> etc. to ensure thread-safety. Since libX11 doesn't want to force threading
> unless its needed, it just uses libc's weak versions. Finally,
> 'Threadplug.so' is loaded which does use threads. This object is linked
> with libpthread.so which is now in the list of libs, crucially *after*
> libc.so.
>
> After all this loading and runtime linking, the question is how does
> libX11 manage to call the right pthread routines? It isn't linked directly
> to libpthread.so and the first weak definition of pthread_foo is from
> libc.so.
It's ugly, but...
The answer is that it's expected to do one of two things:
o The framework supports loading of threaded modules, and
therefore the framework itself is limked against libc_r,
which means that libX11 is linked against libc_r, and
get the pthreads complete mutex/cond/etc. code.
o The framework doesn't support loading of threaded modules,
in which case a threaded module is either expected to:
o Serialize calls to X11 functions through a single
worker thread, OR
o dlopen libX11 after dlopen of libc_r, and then
use threads through its own stub references, OR
o Be linked against libc_r and libX11 (in that order)
so that it gets a different instance of the library
in question; the reentrancy issue only applies to
the threads against a given library instance
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
