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.)

<> 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  -  [EMAIL PROTECTED]
> **  No cross posts or HTML encoding!  **
> (Related lists -
> )

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to