Dieter Maurer <dieter@handshake.de> wrote on 05/03/2004 01:48:57 PM:
The reason why I believe Python is to blame:
With Python 2.1.3, a SIGSEGV in one thread killed them all; with Python 2.3.3, a SIGSEGV in one thread kills one of them (the main thread, not the thread that got the SIGSEGV) but brings the others in a funny state.
You are right. This change: <http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Python/thread_pthread.h?r1=2.32&r2=2.33> causes new threads to be created with signals blocked. (the commit messages, and a lot of the threading code in Python talk about "except for the main thread." I'm not sure if Python's threading abstraction has any concept of a main thread, but POSIX has none. All threads are peers.) <http://pauillac.inria.fr/~xleroy/linuxthreads/faq.html#J.3> discusses how the POSIX spec defines asynchronous signals to be sent to "the process as a whole", which runs afowl with the older Linux threading model, in which threads are really cleverly disguised processes and each thread has a PID. The switch in the signal handling between 2.1.3 and 2.3.3 (subsequent threads after the initial thread are created with signals blocked) explicitly triggers this LinuxThreads bug.
This is on the same OS (Linux 2.4 kernel without NPTL).
Apparently, Python's handling of SIGSEGV signals changed between 2.1.3 and 2.3.3.
In an earlier post, someone reported that Python explicitely blocks most signals in non-main threads. I verified that in the SIGSEGV case above, all remaining threads had "SIGSEGV" blocked.
I may try to change Python to not block SIGSEGV and see whether we get again the old Python 2.1.3 behaviour.
-- Dieter
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )