This is the mail archive of the
glibc-bugs@sources.redhat.com
mailing list for the glibc project.
[Bug nptl/914] pthread_atfork hangs thread after fork
- From: "mkwasigr at intercope dot com" <sourceware-bugzilla at sources dot redhat dot com>
- To: glibc-bugs at sources dot redhat dot com
- Date: 2 May 2005 13:59:09 -0000
- Subject: [Bug nptl/914] pthread_atfork hangs thread after fork
- References: <20050502122955.914.mkwasigr@intercope.com>
- Reply-to: sourceware-bugzilla at sources dot redhat dot com
------- Additional Comments From mkwasigr at intercope dot com 2005-05-02 13:59 -------
I think - but am not yet 100% sure - that my testcase is wrong. Apologies in
case this turns out to be the case, I didn't intend to waste anybodies time!
I just rechecked my testcase on Solaris 8 and found that it behaves exactly as
on RHAS 4 with NPTL. I then rechecked the source of my testcase and came to the
conclusion that the "hang" of the thread is caused by main() holding the lock
most of the time blocking fork() in the thread. The default thread scheduling
method obviously lets main() running for most of the time. I had the (wrong?)
perception that threads queue up on a mutex and are executed in FIFO order. This
appears to be wrong because if I add another sleep(1); after Unlock(); in main,
then both threads issue their message every second.
So please excuse me having filed this "bug" a little too soon but maybe someone
can verify if I'm correct saying that my testcase is not.
Thanks for your time and patience...
BTW: The testcase segfaults on a LinuxThreads. Please let me know if I should
file a bug report against LinuxThreads.
Thanks again and best regards,
- Michael
--
http://sources.redhat.com/bugzilla/show_bug.cgi?id=914
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.