STINNER Victor <victor.stin...@haypocalc.com> added the comment: > 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),
Oh yes, it can be a problem. > and the most important one - especially for real-time signals - is > that the handlers are executed synchronously, when Py_CheckSignals() > is called. Evaluate Python code in a signal handler is really not a good idea! And because of the GIL, I don't think that we can do better. But with the GIL of Python 3.3, the Python signal handler will be called "immediatly" before the next instruction, instead of having to wait something like 100 Python instructions (sys.getcheckinterval()). On this point, Python 3.3 is better than all previous versions. > 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: > (...) > drawbacks: > - might be a bit slower, because of the read syscall > - consumes 2 FDs Consume 2 FDs can be surprising. We cannot do that by default (just to have in-order or real time signals). > - have to reinit the pipe on fork Oh yes, it can be a problem. > - does Windows have pipe/read/write? Do you really think that Windows supports real time signals? :) Windows has pipes: see the Connection object of the multiprocessing module (Antoine is working on this topic). But I don't remember if they can be used as POSIX files (using file descriptors). > - maybe overkill > > But I'm really not sure that fixing this is worth it... It looks like your reimplements the whole signal machinery between the kernel and the application... But anyway, we need something between the C signal handler and the Python signal handler (because we cannot execute Python code in a C signal handler). Well, we can imagine to have an option/function to enable real time and/or in-order signals (e.g. using pipes). Can we call this mode "real time"? Real time means that we warranty a maximum response time. > By the way, to be pedantic, in the current code, wakeup_fd and > Handlers should be volatile, and tripped should be sig_atomic_t. Yes. Can you please write a patch for this? ---------- _______________________________________ 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
