mysterious hang in pthread_create

[Daniel Eischen]

On Sat, 30 Aug 2008, Kostik Belousov wrote:

> On Sat, Aug 30, 2008 at 11:32:35AM -0400, Daniel Eischen wrote:
>> On Fri, 29 Aug 2008, Kostik Belousov wrote:
>>>
>>> As demonstrated by Andriy' example, we need _thr_rtld_init() be called
>>> before any rtld locks are given chance to be acquired. _thr_rtld_init()
>>> shall be protected from repeated invocation, and _thr_setthreaded()
>>> implements exactly this.
>>>
>>> If calling _thr_setthreaded(1) has not quite right intent, could you,
>>> please, suggest satisfying solution ?
>>
>> I'm not sure I _quite_ understand the problem, but why
>> wouldn't you have the same potential problem with some
>> other library (without libthread)?  I'll have to go back
>> and read the beginning of the thread - I just kinda came
>> in at the end.
>
> Sure, for appropriate value of any. If you mean whether the same problem
> would arise for any threading library that supplies locking implementation
> for rtld, then certainly yes. I looked over and patched only libthr
> since this is the only survived library for now.

What I mean is, is fixing libthr a solution that will work
for cases?  Or, is libthr doing something wrong?  I can't
really see that it is.

libthr assumes that everything is single-threaded (or
serialized, I guess) before a thread is created.  I
am looking at this thread:

   http://docs.freebsd.org/cgi/getmsg.cgi?fetch=5235+0+current/freebsd-threads

Where is the corresponding unlock for the wlock_acquire()?
I guess this is the problem.  When would this normally
be released (without libthr being linked in)?

Also, the __isthreaded flag is used in libc to avoid taking
locks unless necessary.  So if you have a single threaded
application that is also linked with libthr, you don't
pay the penalty of locking overhead.  Lots of 3rd-party
libraries link with a threads library, so an application
may not even know it is "threaded".

>
> Anyway, I do not insist on the proposed solution, and definitely
> prefer the change that is well aligned with libthr architecture.

I'm not arguing anything, I just don't know that the problem
lies within lib<insert thread library here>.  Of course, the
rtld init stuff could be pulled out and done in thread
initialization instead of thr_setthreaded().  That doesn't
leave much in thr_setthreaded, and it also adds locking
overhead into rtld for single-threaded programs that are
linked with libthr...

-- 
DE