== A gotcha with Python's new _signal.siginterrupt()_ Python 2.6 added a _siginterrupt()_ function to the [[signal module http://docs.python.org/library/signal.html]], so that you can deal with [[the _EINTR_ problem PythonEINTR]]. Unfortunately it doesn't necessarily do what you want, because of [[CPython signal handler semantics CPythonSignals]]. (Ob-attribution: _signal.siginterrupt()_ was brought to my attention by a commentator on the [[_EINTR_ entry PythonEINTR]].) What you probably want when you combine _siginterrupt()_ and a signal handler, and what a lot of people probably think that they are getting, is that when your program is sitting in a system call and gets a signal, your signal handler function gets called and does its thing while the system call just keeps going, none the wiser. (This is what happens in C, more or less.) What you get instead is that ~~processing the signal is deferred until the system call completes~~. Your program is sitting in a system call, gets a signal, and (as far as your Python code is concerned) absolutely nothing happens until the system call completes, whenever that is. Only then does your signal handler function wake up and do its thing. This happens because CPython only runs Python signal handler functions when control returns to the bytecode interpreter. System calls failing with _EINTR_ is the brute force mechanism that normally causes this to happen relatively soon after your program gets a signal; the program gets a signal, the system call fails with _EINTR_, the C code making the system call notices this and raises an exception, which returns control to the bytecode interpreter. When system calls don't get _EINTR_ any more, the whole chain of events stops (well, never gets started) and there you are, waiting for the system call to finish normally. One might hope that Python's _siginterrupt()_ does something clever to get around this, but it doesn't; it is strictly a wrapper for the C library _siginterrupt(3)_ function. (It probably has to be, since I think that doing otherwise would require C module API changes.) There are probably situations and signal handlers where this is acceptable, or at least the least worst choice, but I do think that it makes _siginterrupt()_ a lot less useful than it first appears. (I also think that this should be explicitly mentioned in the _siginterrupt()_ description, although you can work it out from the current documentation if you put all of the pieces together.)