This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author jasonlowe
Date 2004-05-13.16:20:44
SpamBayes Score
Marked as misclassified
Logged In: YES 

Argh!  I thought we had a relatively clean solution, but it
appears there's a stumbling block with the pthread_kill()
approach.  pthread_kill() is not guaranteed to be
async-signal-safe, and nuggets found on the net indicate
there's no portable way to redirect a process signal from
one thread to another:

Given that we can't safely call pthread_kill() from the
SIGINT handler directly, there might be another way to solve
our problems with pthread_atfork().  Here's my thinking:

- Block SIGINT in all threads except the main (readline) thread.

- Register via child process handler via pthread_atfork()
that sets the SIGINT action for the child process back to
the default.

Unfortunately this fix isn't localized to the readline
module as desired, but it may solve the problems.  SIGINT
routing will be forced to the readline thread, and child
processes won't have SIGINT blocked, solving bug 756940. 
The IRIX thread signal delivery model (i.e.: broadcast) may
cause problems since SIGINT may be pending when we attempt
to set the action to default.  Having SIGINT pending when
the handler is changed to default would kill the child
process.  Maybe having the child process set the disposition
to ignore and then to default would safely clear any pending
SIGINT signal?

I'll try to run some experiments with the pthread_atfork()
approach soon, but work and home life for me is particularly
busy lately.  Apologies in advance if it takes me a while to
respond or submit patches.

If we're interested in a timely fix, would it be useful to
break up the fix in two stages?  I think we can all agree
that the current approach of blocking ALL signals in created
threads is a Bad Thing.  What if we implement a quick,
partial fix by simply change the existing code to only block
SIGINT?  This should be a two-line change to
thread_pthread.h where "sigemptyset(&newmask);
sigaddset(&newmask, SIGINT);" is used instead of
"sigfillset(&newmask);".  I see this partial fix having a
number of benefits:

- Easy change to make.  No extra stuff to check for in
configure or calls to things that may not exist or work

- Much less risky than trying to fix all the problems at
once.  The change only opens up signals to threads that
Python-2.1 is already allowing through.

- Should solve the SIGSEGV zombie problem and Guido's
SIGTERM annoyance, although it would still have the problem
reported in bug 756940.
Date User Action Args
2007-08-23 14:14:06adminlinkissue756924 messages
2007-08-23 14:14:06admincreate