Logged In: YES 
user_id=119306

The original bug that added the signal blocking, #465673, seems 
to be exposing itself via a combination of  threads and readline. Is 
it possible that it is the problem is there and not within the signal 
handling code itself? (especially since it installs and removes a 
SIGINT handler, possibly causing a race condition with the code 
within the signal handler when it re-installs itself. On systems that 
have sigaction, should python need to re-install handlers at all? )

I'm tempted to try to the following, and if it works submit a patch.  
Does this seem like it would be the right direction?

* Remove the section of thread creation that blocks signals.

* Look for sections of code may have reentrancy issues, like:

**  On machines with reliable signals, keep the signal handler 
installed, rather than reinstalling it within the handler.

** Change Py_AddPendingCall to use a real semaphore, if 
available, rather than a busy flag.

** Change readline.c to use more thread safe constructs where 
available (arrange so that the longjmp out of the signal handler is 
only executed for the thread that is using readline, and use 
siglongjmp if available)

and then see if issues like this one are solved without 
reintroducing issues from 465673.