[Dieter Maurer]
> The reason why I believe Python is to blame:

Then this should really move to a Python bug tracker.

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

SIGSEGV is mentioned only in Python's signalmodule.c.  You can use ViewCVS
to show a diff between the 2.1.3 state of that (tag r213) and current HEAD.
I don't see any possibly relevant differences:


> In an earlier post, someone reported that Python explicitely
> blocks most signals in non-main threads.

I'm not clear on exactly what "blocked" means.  The comments at the top of
signalmodule.c say:


   When threads are supported, we want the following semantics:

   - only the main thread can set a signal handler
   - any thread can get a signal handler
   - signals are only delivered to the main thread


That's the intent.

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

The relevant change is probably in Python/thread_pthread.h.  Guido added a
call to pthread_sigmask (or sigprocmask, depending on how broken the
platform pthread support is ...), to PyThread__init_thread(), in revision
2.33.  The checkin comment begins:

    Add SF patch #468347 -- mask signals for non-main pthreads, by
    Jason Lowe:

    This patch updates Python/thread_pthread.h to mask all
    signals for any thread created. This will keep all
    signals masked for any thread that isn't the initial
    thread.  For Solaris and Linux, the two platforms I was
    able to test it on, it solves bug #465673 (pthreads
    need signal protection) and probably will solve bug
    #219772 (Interactive Interpreter+ Thread -> core dump
    at exit).

That was added before 2.1.3, but looks like it didn't get backported to the
2.1.3 maintenance branch before 2.1.3 was released.

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to