"Tim Peters" <tim@zope.com> wrote on 05/03/2004 03:47:31 PM:
[Dieter Maurer] I'm not clear on exactly what "blocked" means.
It has a very specific meaning with Unix signals. The kernel still has the signal for the process waiting in a queue, but the process has told the kernel that it is interested in receiving it yet. Blocking is set by the pthread_sigmask or the sigprocmask functions mentioned below.
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. [stuff deleted]
For a POSIX compatible pthread library, Python's current implementation, (set all signal handlers in the initial thread, start all subsequent threads with signals blocked) will produce the intended Python threading model behavior described above. For LinuxThreads, blocked signals in threads is exactly where it is imcompatible with POSIX. Since LinuxThreads are (not so) cleverly disguised processes, each with their own PID, signals can be sent to a thread and if blocked will never get rerouted to another thread. (When left to the default signal handling is to terminate, and a thread is left to the default the internal thread management will notice that one thread died of a signal and will handle the rest.)
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 ...),
In order to get LinuxThreads to support the Python's threading semantics, what probably needs to be done is to have PyThread_init_thread set all handlers to call kill(main_thread, sig) to signal the main thread.