Hi Steve,
Steve Graegert wrote:
> 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).
If i understand correctly what you're saying, you cannot have something
like:
int main(int argc, char *argv[]) {
/* ... */
foo = dlopen("bar.so");
/* use bar.so functions, clean, etc... */
}
if bar.so is multithreaded (and thus, linked to libpthread.so) and you
don't compile your main program with -lpthread option.
did i understand you right ?
this would mean you may need to link against pthread library, just in
case the library(ies) you dlopen might use it ?
> 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.
>
>
Ben
-
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
