Re: threads and kernel

Hi,

Steve Graegert wrote:
> Benoit,
>
> On 10/22/07, Benoit Fouet <[email protected]> wrote:
>   
>> Hi Steve,
>>
>> Steve Graegert wrote:
>>     
>>> Hi Benoit,
>>>
>>> On 10/22/07, Benoit Fouet <[email protected]> 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 ?
>>     
>
> Linking against a multi-threaded library at compile time, turns the
> main program into a multi-threaded program even though no use of
> threads is being made at all.
>
>   

i agree, but this was not what i asked.
consider a library foo using threads.
consider a main program bar only linked to dl.
chat you said is that bar cannot use sanely foo functions, because it is
not multithreaded itself, right ?

Ben