mysterious hang in pthread_create
Kostik Belousov
kostikbel at gmail.com
Sat Aug 30 15:56:28 UTC 2008
On Sat, Aug 30, 2008 at 11:32:35AM -0400, Daniel Eischen wrote:
> On Fri, 29 Aug 2008, Kostik Belousov wrote:
>
> >On Fri, Aug 29, 2008 at 12:25:09PM -0400, Daniel Eischen wrote:
> >>On Fri, 29 Aug 2008, Kostik Belousov wrote:
> >>
> >>>On Fri, Aug 29, 2008 at 05:18:18PM +0300, Andriy Gapon wrote:
> >>>>
> >>>>Kostik, thanks!
> >>>>
> >>>>on 29/08/2008 17:10 Kostik Belousov said the following:
> >>>>>I am wondering why did you not fixed it youself with all this
> >>>>>information.
> >>>>
> >>>>I am wondering that myself now :-)
> >>>>I got bogged in rtld details and simply didn't think about the solution
> >>>>of doing setthreaded earlier.
> >>>>
> >>>>I will try your patch a couple of hours later.
> >>>>BTW, a forward question - should this patch help in the case of an
> >>>>exception thrown (and caught) before main(), i.e. in constructors of
> >>>>static/global objects?
> >>>If the objects are from the executable, then yes. I do not know about
> >>>present situation, but some time ago g++ and several other compilers
> >>>called ctr for global objects from the main() function. Regardeless
> >>>of this, init for main executable shall be called after init for
> >>>dependencies is finished. See initlist_add_objects().
> >>>
> >>>On the other hand, ctr calls from linked dso may get fixed in regard
> >>>of exception throwing, or may not, depending on the relative order of
> >>>the dso loading against libthr.
> >>>
> >>>>
> >>>>>Anyway, patch below seems to work for me. David may have an opinion on
> >>>>>the change.
> >>>>>
> >>>>>diff --git a/lib/libthr/thread/thr_init.c
> >>>>>b/lib/libthr/thread/thr_init.c
> >>>>>index f96bba9..785d610 100644
> >>>>>--- a/lib/libthr/thread/thr_init.c
> >>>>>+++ b/lib/libthr/thread/thr_init.c
> >>>>>@@ -355,6 +355,9 @@ _libpthread_init(struct pthread *curthread)
> >>>>> if (_thread_event_mask & TD_CREATE)
> >>>>> _thr_report_creation(curthread, curthread);
> >>>>> }
> >>>>>+
> >>>>>+ if (_thr_isthreaded() == 0)
> >>>>>+ _thr_setthreaded(1);
> >>>>>}
> >>>>>
> >>>>>/*
> >>
> >>I think the intent of __isthreaded (and _thr_setthreaded()) was
> >>to be set if there were more than 1 thread, not to indicate that
> >>the thread library has been initialized.
> >
> >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.
Anyway, I do not insist on the proposed solution, and definitely
prefer the change that is well aligned with libthr architecture.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-threads/attachments/20080830/9a6e69da/attachment.pgp
More information about the freebsd-threads
mailing list