homepage

In a pthreads environment, signals sent asynchronously 
from things like kill() or the terminal driver are sent to the 
process and can be handled by any thread. Signals that are 
sent synchronously from the instruction stream (signals like 
SIGSEGV, SIGFPE, or SIGILL) are only delivered to the 
thread that executed the instruction.
The current Python threads, when implemented via 
pthreads, blocks these synchronous signals and so thread 
that generates one can hang the entire process.
The attached patch will remove some signals the list of 
signals to be blocked. The list of signals to be removed 
correspond to signals that can be generated synchronously.

Logged In: YES 
user_id=31435
Boosted the priority in the hopes this will get looked at before 
2.3.4. Unfortunately, I'm not in a position to test a pthreads 
patch.
I'll note that the good comments about *why* this change is 
being entertained would be far more useful in the code than in 
the patch comment here.

Logged In: YES 
user_id=6380
As Tim mentioned, this is a possible stopgap fix for bug 949332.
While many objections have been raised, I still think this
is a safer approach than some of the more advanced suggestions.
(Too bad it doesn't solve my own, related problem, which is
that SIGTERM is ignored by default in a process started from
a Python thread.)

Logged In: YES 
user_id=265829
This patch addresses a serious problem in Zope2 (and
probably other multi-threaded) production environments with
LinuxThreads. A crash of one thread brings other threads in
an unsane state which they leave only on "kill -9". This
lets Guido's "zdeamon" automatic restart logic fail. Even
manual restarts are a bit difficult as each individual
thread must be sent a "kill -9".
Applying the patch lets at least the process die properly. I
am not yet sure whether the return code is appropriate for
"zdeamon" to restart the process. I will check that soon and
report back.

Logged In: YES 
user_id=265829
I verified that the return code is appropriate.

Logged In: YES 
user_id=119306
The changes in <http://sourceforge.net/tracker/
?func=detail&aid=960406&group_id=5470&atid=305470> are 
probably more appropriate than this patch.

Logged In: YES 
user_id=6656
Closing in favour of 960406.