Logged In: YES 
user_id=56897

There didn't seem to be an outcome from the python-dev
discussion regarding system() and pthread_atfork().  The
thread indicates that system() indeed is supposed to call
atfork handlers, so therefore RedHat 9 is violating the
pthread standard in that sense.  (Whether or not they'll fix
it is another issue.)  There's also mention that os.system()
may be changed to not call system() because of the atfork()
problem.  If the changes to avoid system() are implemented,
would the pthread_atfork() approach still be problematic?

As Martin Loewis points out, we could always implement the
signal fixup in the child directly after the fork() if
Python routines are being used to do the fork() in the first
place.  However if we're concerned about native modules that
directly call fork() then it seems our choices are a
pthread_atfork() approach or an approach where SIGINT isn't
blocked.  Without an async-signal-safe way to route a signal
from one thread to another, I don't see how we can leave
SIGINT unblocked in all threads.

Re: Py_AddPendingCall. That approach might work in many
cases, but I assume it doesn't work well when all threads
are currently busy in native modules that are not
well-behaved.  For example, I have two threads: one in
readline() and the other blocked in a native call that, like
readline(), doesn't return control on EINTR.  If the SIGINT
is sent to the readline thread, the signal handler could
check the thread ID and do the longjmp() since we're the
proper thread to do so.  If the SIGINT is sent to the other
thread, the callback added by Py_AddPendingCall() won't
necessarily be processed any time soon because no threads
are going to return control (in a timely manner) to Python.
 To make matters worse, apparently even something as simple
as pthread_self(), which we'd use to get the thread ID,
isn't async-signal-safe on all platforms.  From what I've
read, none of the pthread functions are guaranteed to be
async-signal-safe.  :-(