"Tim Peters" <[EMAIL PROTECTED]> 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
> 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.

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

Reply via email to