Message135871
> 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. |
|
Date |
User |
Action |
Args |
2011-05-12 21:52:00 | neologix | set | recipients:
+ neologix, pitrou, vstinner, nadeem.vawda, sdaoden |
2011-05-12 21:51:59 | neologix | set | messageid: <1305237119.97.0.720079360847.issue12060@psf.upfronthosting.co.za> |
2011-05-12 21:51:59 | neologix | link | issue12060 messages |
2011-05-12 21:51:59 | neologix | create | |
|