Processed: Re: Bug#654783: race condition in libpthread causes hangs in python2.7 testsuite
Processing commands for cont...@bugs.debian.org: > tag 654783 pending Bug #654783 [libc0.1] race condition in libpthread causes hangs in python2.7 testsuite Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 654783: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=654783 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.133494699830980.transcr...@bugs.debian.org
Bug#654783: race condition in libpthread causes hangs in python2.7 testsuite
tag 654783 pending thanks El 20 d’abril de 2012 8:47, Petr Salinger ha escrit: > In the original (plain linuxthreads) code, with thread implemented as > freebsd process, the wakeup signal is sent to thread manager from kernel, > after exit of thread. > > In current variant, with thread implemented as freebsd kernel thread, > the wakeup signal is sent to thread manager from userspace, a few moments > before exit. It is an expected race condition. It is also the reason, why > "|| main_thread_exiting" have been added. I expected, that loss of a > wakeup does not matter, the "child thread" will be "eaten" only slightly > later, when another thread exits and sends wake up. The only problem should > be, when there is no another thread, it should be solved by > "|| main_thread_exiting". But it does not suffice. > > The "try eat dead child" everytime is just workaround. Yep, eating dead children everytime doesn't sound like the cleanest option to me either ;-) > The better way might be to add atomic counter > [using gcc's __sync_fetch_and_add()] to track the number of expected "dead > or soon to be dead" child > and "try to eat dead child" when the number is above zero. Thanks for the heads-up. I notice you already fixed this in pkg-glibc SVN. Maybe it's not worth improving further... (IMHO time would be better spent on NPTL). Thank you! -- Robert Millan -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOfDtXOQpP8BOjXXS5vHTLOFW=yr-kyvvw8fdg8syntxhi5...@mail.gmail.com
Bug#654783: race condition in libpthread causes hangs in python2.7 testsuite
That's really nice. Petr, could you give some explanation on that one-line patch you provided? Is it supposed to be the correct fix or is more work necessary? I'm not familiar with the whole picture but if you give some pointers I may be able to help. In the original (plain linuxthreads) code, with thread implemented as freebsd process, the wakeup signal is sent to thread manager from kernel, after exit of thread. In current variant, with thread implemented as freebsd kernel thread, the wakeup signal is sent to thread manager from userspace, a few moments before exit. It is an expected race condition. It is also the reason, why "|| main_thread_exiting" have been added. I expected, that loss of a wakeup does not matter, the "child thread" will be "eaten" only slightly later, when another thread exits and sends wake up. The only problem should be, when there is no another thread, it should be solved by "|| main_thread_exiting". But it does not suffice. The "try eat dead child" everytime is just workaround. The better way might be to add atomic counter [using gcc's __sync_fetch_and_add()] to track the number of expected "dead or soon to be dead" child and "try to eat dead child" when the number is above zero. And (of course) in long term, do not use manager thread anymore. Petr -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lrh.2.02.1204200833090.20...@sci.felk.cvut.cz
