On 9/9/06, Nick Maclaren <[EMAIL PROTECTED]> 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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
