Hi Benoit, On 10/22/07, Benoit Fouet <benoit.fouet@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
