Charles-François Natali <neolo...@free.fr> added the comment: > If the C signal handler is called twice, the Python signal handler is only > called once.
It's not the only shortage with the current implementation regarding (real-time) signals. Another one is that they're delivered out-of-order (lowest-numbered signal first), and the most important one - especially for real-time signals - is that the handlers are executed synchronously, when Py_CheckSignals() is called. While we can't do much about the the later, there's at least a way to handle the other issues, a small variant of the self-pipe trick: - in the signal module initialization code, create a pipe with both ends set to non-blocking - in the signal handler, write the signal received to the pipe (just like what's done for wakeup_fd) - in Py_CheckSignals(), read from the pipe: the signals will be read in order, as many times as they were received. Call the handler for each signal read from the pipe. advantages: - it's async-safe - signals are handled in order - signal handlers are called the correct number of times - you don't have to walk through the whole array of signal handlers, since you know exatly what signals have been received drawbacks: - might be a bit slower, because of the read syscall - consumes 2 FDs - have to reinit the pipe on fork - does Windows have pipe/read/write? - maybe overkill But I'm really not sure that fixing this is worth it... By the way, to be pedantic, in the current code, wakeup_fd and Handlers should be volatile, and tripped should be sig_atomic_t. ---------- nosy: +neologix _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12060> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
