Re: threads and kernel

["Steve Graegert" <graegerts@gmail.com>]

Hi Benoit,

On 10/22/07, Benoit Fouet <benoit.fouet@purplelabs.com> wrote:
> Hi,
>
> Steve Graegert wrote:
> > As a side note: you can safely use dlopen()  to load shared libraries,
> > whether or not they depend on libpthread.so, as long as the main
> > program was initially threaded.  The other way round is dangerous and
> > mostly not allowed.
> >
> >
>
> could you please elaborate a bit on that ? i cannot see why this is
> dangerous.

I was referring to making an application multithreaded at runtime.
Therefore you cannot use dlopen() to dynamically add libpthread.so to
a process when the main program is not __initially threaded__.  By
"initially threaded" I mean that the libpthread.so  library is
initialized at program start, either because the main program links
against libpthread.so directly, or because it links against some other
shared library that links against libpthread.so.

Dynamically changing the process environment from "nonthreaded" to
"threaded" is dangerous and rarely useful (I actually doubt that this
"feature" is useful at all).  Only a few systems implementing POSIX
threads allow the possibility (for example, libc.so on many systems
contains "stub" versions of the POSIX functions that are preempted by
linking with libpthread.so but will not be preempted by later loading
libpthread.so with dlopen()).  In other words, calls to
pthread_create() might fail with ENOSYS, and pthread_mutex_lock()
might continue to succeed without any memory references to the lock.

	\Steve

--

Steve Grägert
DigitalEther.de
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html