What happens inside asyncio.run() when the user presses Ctrl-C?

## How a signal reaches Python at all Ctrl-C makes the terminal send `SIGINT` to the foreground process group. CPython's C-level handler does almost nothing: it sets a flag and writes a byte to the wakeup file descriptor. The *Python* handler runs later, in the main thread, between bytecodes. Two consequences matter for asyncio. First, only the main thread ever runs signal handlers — an event loop running in a worker thread receives no signal handling whatsoever. Second, a loop blocked in `select()` with a long timeout has to be woken, which is what the wakeup file descriptor (`signal.set_wakeup_fd()`) is for. ## The default handler is hostile to a loop `signal.default_int_handler` raises `KeyboardInterrupt` wherever the main thread happens to be. Inside an asyncio program that point is almost always somewhere in the event loop's own machinery, not in your code. Before 3.11 that is exactly what happened: `KeyboardInterrupt` propagated out of `run_until_complete()`, the main task was left un-cancelled and never got its `finally` blocks, and you were rewarded with "Task was destroyed but it is pending" on the way out. ## What 3.11 changed, and 3.14 still does `asyncio.Runner.run()` installs its own `SIGINT` handler before driving the main task, guarded twice: it must be on the main thread, and the current handler must still be `signal.default_int_handler` — if you installed your own, yours is respected and left alone. The handler restores the previous one in a `finally`, so the change does not leak past the call. On the **first** interrupt the handler does two things and returns: it calls `cancel()` on the main task, and it schedules a no-op with `loop.call_soon_threadsafe()` purely to wake a loop sitting in `select()`. No exception is raised at that moment. Your coroutine then receives `CancelledError` at its next suspension point, exactly like any other cancellation, and its `finally` blocks and `async with` exits run normally while the loop is alive. When the main task ends cancelled, `Runner.run()` inspects it: if the interrupt did the cancelling and `Task.uncancel()` brings the count back to zero, it raises `KeyboardInterrupt`. That is what keeps the familiar shape working: ```python try: asyncio.run(main()) except KeyboardInterrupt: print("stopped by the operator") ``` There is a sharp edge here. If your main coroutine catches the `CancelledError` and returns a value instead of letting it propagate, `asyncio.run()` returns normally and **no** `KeyboardInterrupt` is raised — the program reports success to whatever ran it. Suppressing cancellation in `main()` therefore quietly changes your exit semantics. On the **second** interrupt the handler raises `KeyboardInterrupt` immediately, from wherever the main thread is. That may be in the middle of teardown, between two cleanup awaits. Operators do press Ctrl-C twice when the first press appears to do nothing, so shutdown work must be safe to interrupt: write to a temporary file and rename, mark records complete only after the write, and never leave a half-updated structure between two awaits. ## SIGTERM is a different story Nothing in asyncio handles `SIGTERM`. Its default disposition kills the process outright — no `finally`, no generator cleanup, no flush. Any service that is stopped by a supervisor rather than by a keyboard must install a handler itself. On Unix: ```python loop = asyncio.get_running_loop() stop = asyncio.Event() for sig in (signal.SIGINT, signal.SIGTERM): loop.add_signal_handler(sig, stop.set) ``` `loop.add_signal_handler()` is the asyncio-native route: the callback is scheduled on the loop and runs on the loop thread like any other callback, so it may touch loop state safely. It is Unix-only — on Windows the proactor loop raises `NotImplementedError`, and you fall back to `signal.signal()` plus `loop.call_soon_threadsafe()` to hop from the signal context onto the loop. Note what the handler above does *not* do: it does not cancel anything. It sets an `asyncio.Event`, and the program's own shutdown path decides what to drain and for how long. That separation is why installing your own `SIGINT` handler in a service is common: you want a controlled drain, not an immediate cancel of the main task. ## Interview-sized summary Ctrl-C is not an exception thrown into your coroutine; it is a signal that the runner turns into a cancellation of one specific task, with `KeyboardInterrupt` re-raised at the end for the caller's benefit. `KeyboardInterrupt` derives from `BaseException`, not `Exception`, so a blanket `except Exception` around your loop body never swallows it — and a blanket `except BaseException` will, which is a reliable way to build a program that cannot be stopped.