Re: threads and kernel

[Benoit Fouet <benoit.fouet@purplelabs.com>]

Hi Steve,

Steve Graegert wrote:
> 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).

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