Dieter Maurer <[EMAIL PROTECTED]> 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:
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.
> Zope-Dev maillist - [EMAIL PROTECTED]
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://mail.zope.org/mailman/listinfo/zope )
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -