Date: Thu, 31 Oct 2002 13:36:33 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Doug Rabson <dfr@nlsystems.com> Cc: Daniel Eischen <eischen@pcnet1.pcnet.com>, ak03@gte.com, current@FreeBSD.ORG Subject: Re: [PATCH: libc]Re: gnome on current Message-ID: <3DC1A261.16B93AF8@mindspring.com> References: <20021031151314.A69202-100000@herring.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DC1A261.16B93AF8>