[Python-Dev] Signals, threads, blocking C functions (original) (raw)

Gustavo Carneiro 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 PyAddPendingCall 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.

More information about the Python-Dev mailing list