[Python-Dev] Signals, threads, blocking C functions

[Gustavo Carneiro]

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 [1], 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.


[1] Although ideally Python wouldn't even have KeyboardInterrupt and
just die on Ctrl-C like any normal program.