Why is doing real work inside a signal.signal() handler unsafe, and what belongs there instead?

## The handler is a re-entrant call, not a thread CPython runs your Python-level handler on the main thread of the main interpreter, at a bytecode boundary, on top of the frame that was executing. There is no separate stack of execution and no isolation. Everything difficult about signal handlers follows from that one fact, and interviewers at senior level are checking whether you have felt it in production rather than read it. ## Failure one: a race with yourself Concurrency bugs are normally explained as two threads interleaving. A signal handler gives you the same class of bug with a single thread, because "between bytecodes" cuts finer than a line of Python. Consider a subscription-billing run that, per account, adds an amount to a running total and then marks the item settled. Those are separate bytecodes. A signal can land between them, and a handler that reads or rewrites the totals sees an amount counted with nothing settled — and if the handler *writes* the shared structure, the interrupted code resumes and overwrites it. A regression pack of 340 accounts that raises the signal at a different point in each case is exactly how a team finds this: the failure is not reproducible at a fixed line, because the interruption point is not fixed. Even a single augmented assignment is unsafe: `total += amount` loads, adds and stores as separate instructions, so a handler that also touches `total` can lose an update. ## Failure two: deadlocking against yourself `threading.Lock` is not re-entrant and, more importantly, has no notion of "the same thread already has it". If the main thread holds a lock and the handler tries to acquire it, the acquire blocks forever waiting for a thread that is stopped inside the handler. This is the single most common way a shutdown handler hangs a process. Any indirect lock counts too: writing to a logging handler, printing, or calling into a library that guards its own state can all take a lock that the interrupted code was already holding. Using `threading.RLock` removes the hang but not the bug — the handler now sails into a critical section whose invariants are half-established, which is a quieter version of the same corruption. ## Failure three: an exception from anywhere If the handler raises, the exception propagates from whatever line the main thread was executing. That is how `KeyboardInterrupt` works, and it means an unremarkable statement can suddenly raise, skipping the rest of a sequence. Code that is not exception-safe at every line becomes wrong in the presence of a raising handler. That is a legitimate design — it is how you stop a runaway loop — but it must be a decision, not an accident, and cleanup must live in `finally` blocks or context managers rather than in the lines that were about to run. ## What the handler should do The standard shape is: record intent, return immediately. ```python stop_requested = False def on_signal(signum, frame): global stop_requested stop_requested = True ``` A single assignment to a module-level name is one bytecode store and is safe. The main loop then tests the flag between units of work — at a point where the totals and the settled markers agree — and performs the shutdown, the flush, or the report there, with the whole language available to it and no re-entrancy risk. The variant for a loop that blocks on file descriptors is to have the handler write one byte to a pipe (or let CPython do it through the wakeup file descriptor) so the blocked wait returns, and then handle the request on the normal path. ## Testing it honestly `signal.raise_signal()` triggers the handler synchronously from the main thread, which lets a test drive the interruption at a chosen point instead of hoping to hit it. Drive it at many different points across your regression pack, assert the invariant after each, and the tearing bugs surface deterministically. Also assert the boring properties: the handler returns quickly, it never blocks, and it holds no lock when it returns. ## What to say in the interview One sentence of mechanism (main thread, between bytecodes, on top of the interrupted frame), two named failures (torn multi-step state, self-deadlock on a held lock), and the rule (set a flag, act at a safe point). That is a complete senior answer, and everything else is elaboration.