Why can KeyboardInterrupt interrupt a shared-cache update midway and leave it inconsistent?

## The scenario A translation-memory updater keeps its segment cache in memory — an in-process dictionary running an 83% hit rate against incoming segments — and each commit touches two things: the entry itself and a counter used to decide when to flush. An operator presses Ctrl-C during a batch, and afterwards the counter disagrees with the number of entries. Nothing in the code can produce that state on any single line, and the same batch replayed by hand is fine. ## How Ctrl-C actually becomes an exception The interrupt is a POSIX signal, and a signal handler runs in a context where almost nothing is safe to do. Python therefore does the minimum in the C handler: it records that the signal arrived and sets a flag on the interpreter, then returns. The evaluation loop checks that flag between bytecode instructions, and *there* — back on solid ground, with the interpreter in a consistent state — it raises `KeyboardInterrupt`. The consequence is that delivery is **asynchronous with respect to your source code**. The exception appears at whichever instruction boundary happens to be next, which can be between two statements of a compound update, or between the subscript store and the counter increment. Your two-line critical section is many bytecodes, and every gap between them is a place the exception can land. This is a genuine race on shared state: the interrupt is an independent event, and the window is every instruction boundary in the mutation. Two related details matter. First, Python only runs signal handlers **in the main thread**, so a worker thread never receives `KeyboardInterrupt` — it keeps running against whatever half-updated state the main thread left behind, and it cannot even observe that a shutdown was requested unless you tell it. Second, since PEP 475 in Python 3.5, a system call interrupted by a signal is retried rather than surfacing `InterruptedError`, *unless* the Python-level handler raises — which the default interrupt handler does. So a blocking read does still get cut short by Ctrl-C; it just no longer produces a spurious `InterruptedError` for signals you handle silently. ## Why the rollback did not run The second half of the bug is hierarchy. `KeyboardInterrupt` derives directly from `BaseException`, deliberately kept off the `Exception` branch so ordinary error handling cannot swallow a shutdown request. That design is correct, and it also means a compensating block written as `except Exception:` is not entered when the interrupt lands. The state is left torn and nothing repairs it. ```python import threading lock = threading.Lock() memory = {"entries": 0} def commit(key, text): with lock: try: memory["entries"] += 1 memory[key] = text except BaseException: memory.pop(key, None) memory["entries"] -= 1 raise ``` Naming `BaseException` here is legitimate precisely because the block repairs state and immediately re-raises; it never decides to continue. A `finally` block achieves the same thing when the cleanup is unconditional, and both run during the unwind that `KeyboardInterrupt` triggers. ## The three real fixes, in order of preference **Shrink the window.** The most robust answer is to make the mutation a single rebinding rather than a sequence: build the new entry, then publish it in one operation whose intermediate state is never visible. Derive the counter from the container instead of maintaining it separately, and there is no invariant left to tear. **Repair on the way out.** Where a multi-step mutation is unavoidable, wrap it in `try`/`finally` or in a broad handler that undoes the partial work and re-raises. Keep the compensating code short — a second Ctrl-C during cleanup raises again inside your handler, so cleanup that itself takes a long time is a new hazard. **Do not let the signal raise at all.** For a batch worker, the cleanest design is cooperative: install your own handler with `signal.signal` for the interrupt signal that merely sets a `threading.Event`, and have the main loop check that event between work items and exit at a boundary you chose. The exception then never fires mid-update, and worker threads can observe the same event and wind down — which the default behaviour cannot give them, since they never see the signal. ```python import signal import threading stop = threading.Event() signal.signal(signal.SIGINT, lambda signum, frame: stop.set()) ``` The tradeoff is that you have taken responsibility for responsiveness: if the loop checks the event only rarely, Ctrl-C appears to do nothing, and operators reach for a harder kill. The usual compromise is to swallow the first interrupt into the event and restore the default handler so a second one raises immediately. ## What an interviewer is listening for That you can explain *why* delivery is asynchronous rather than just asserting it; that you connect the missing rollback to `KeyboardInterrupt` sitting outside `Exception`; that you know signal handlers run only in the main thread; and that your first instinct is to shrink the critical section rather than to add ever-broader handlers around it.