[Python-Dev] Signals, threads, blocking C functions
gjcarneiro at gmail.com
Sat Sep 9 13:38:03 CEST 2006
On 9/9/06, Nick Maclaren <nmm1 at cus.cam.ac.uk> wrote:
> I was hoping to have stopped, but here are a few comments.
> I agree with Jan Kanis. That is the way to tackle this one.
Alas, it doesn't work in practice, as I already replied.
> Despite the implication, the code of Py_AddPendingCall is NOT safe
> against simultaneous registration. It is just plain broken, I am
> afraid. The note starting "Darn" should be a LOT stronger :-)
Considering that this code has existed for a very long time, and
that it isn't really safe, should we even bother to try to make
signals 100% reliable?
I remember about a security-related module (bastion?) that first
claimed to allow execution of malicious code while protecting the
system; later, they figured out it wasn't really safe, and couldn't be
safe, so the documentation was simply changed to state not to use that
module if you need real security.
I see the same problem here. Python signal handling isn't _really_
100% reliable. And it would be very hard to make Py_AddPendingCall /
Py_MakePendingCalls completely reliable.
But let's think for a moment. Do we really _need_ to make Python unix
signal handling 100% reliable? What are the uses for signals? I can
only understand a couple of uses: handling of SIGINT for generating
KeyboardInterrupt , and handling of fatal errors like SIGSEGV in
order to show a crash dialog and bug reporting tool. The second use
case doesn't demand 100% reliability. The second use case is
currently being handled also in recent Ubuntu Linux through
/proc/sys/kernel/crashdump-helper. Other notable uses that I see of
signals are sending SIGUSR1 or SIGHUP to a daemon to make it reload
its configuration. But any competent programmer already knows how to
make the program use local sockets instead.
 Although ideally Python wouldn't even have KeyboardInterrupt and
just die on Ctrl-C like any normal program.
More information about the Python-Dev