What does signal.siginterrupt(sig, False) change, and why does CPython leave calls interruptible by default?

## The kernel-level knob When a handler is installed for a signal, POSIX lets the installer choose what happens to a system call the signal interrupts. With the restart behaviour enabled, the kernel reissues the call itself once the handler returns, and the program never sees an error. With it disabled, the call fails with `EINTR` and the program must decide what to do. `signal.siginterrupt(signalnum, flag)` exposes that choice: `flag=True` means "interrupt calls" (fail with `EINTR`), `flag=False` means "restart them". The naming trips people up — the argument describes *interrupting*, so passing `False` is what turns kernel restarting on. ## Why CPython chooses interruptible At first glance kernel-level restarting looks like exactly what a high-level language wants: the call transparently completes and nobody writes retry code. CPython nonetheless registers handlers in interruptible mode, and `signal.signal` implicitly resets a signal to that mode whenever you register a handler for it. The reason is where Python-level handlers can run. A C signal handler may not execute Python code — it runs asynchronously on an arbitrary stack, and allocating or taking interpreter locks there is unsafe. So CPython's C handler only records that the signal arrived, and the callable you registered runs later, in the main thread, at the interpreter's next check between bytecodes. If the kernel restarts the interrupted call, the process goes straight back to blocking, and there is no next bytecode until the call finally returns. A handler installed to stop the program then does not run until the wait ends — which for a socket that never receives anything is never. Interruptible mode guarantees the call returns control to the interpreter promptly, so your handler runs when the signal arrives rather than whenever the I/O happens to finish. ## How it combines with automatic retry Interruptible mode used to have an obvious cost: the interrupted call surfaced as `InterruptedError`, and correct code had to retry it by hand. Since Python 3.5 (PEP 475) the interpreter reissues the call for you after running the handler, recomputing any remaining timeout from a monotonic deadline. That combination is why setting the restart behaviour is almost never useful in Python: you already get prompt handler dispatch *and* an uninterrupted-looking call, with a bounded timeout on top. Kernel-level restarting gives you only the second of the three. There is a case where people still reach for it: a signal used purely as a bookkeeping notification, with no Python-level handler at all, where you would rather the kernel absorb it entirely. Even then the gain is marginal, and the cost is that any future handler on that signal becomes latent — it will fire only when the blocking call ends. ## The reset footgun The documented behaviour of `signal.signal` is to reset the restart behaviour to interruptible for the signal it registers. So this is a no-op: ```python signal.siginterrupt(signal.SIGUSR1, False) signal.signal(signal.SIGUSR1, my_handler) # silently resets it ``` and the `signal.siginterrupt` call must follow the registration, not precede it. Since registration often happens in library setup code you do not control — a framework installing its own handler at start-up, or a reload path re-registering handlers — a setting made once at import time can quietly evaporate. That fragility is another reason to treat the flag as something you inspect while debugging rather than something you rely on. ## What to say about it Name the three layers cleanly: the kernel decides whether an interrupted call fails or restarts; the interpreter decides whether to reissue a failed call; and your handler decides, by returning or raising, whether that reissue happens at all. Python puts the decision in the middle layer on purpose, because that is the only layer that can run your code.