Why can't signal.alarm time out a blocking call running in a worker thread?

Signals are a **process**-level facility, not a thread-level one, and CPython layers a further simplification on top: all Python-level signal handling happens in the main thread. Understanding those two sentences is the whole answer. ### What the kernel does, and what CPython does When `SIGALRM` is delivered, the C handler CPython installed runs on whichever thread the kernel picked. That handler is deliberately tiny: it records which signal arrived and sets a flag telling the interpreter that a signal is pending. It cannot call Python code — almost nothing is safe to do inside a C signal handler. The actual Python callable you registered runs later, from the eval loop, **and only from the main thread's eval loop**. The main thread checks the pending-signal flag between bytecode instructions, calls your handler, and if that handler raises, the exception propagates from whatever the main thread happened to be executing. A worker thread never checks that flag. It has no opportunity to run your handler and no exception is ever injected into it. If the worker is parked inside a blocking read, it stays parked. ### The two restrictions people mix up **Registration is main-thread-only.** Calling `signal.signal(signal.SIGALRM, handler)` from a worker raises `ValueError: signal only works in main thread of the main interpreter`. That is a hard, explicit refusal, and it is the one most people remember. **Arming is not restricted.** `signal.alarm` and `signal.setitimer` are thin wrappers over a process-wide interval timer, and calling them from a worker thread works fine — no exception, the timer arms, the signal is delivered on schedule. This is the trap: the code looks like it worked. It did arm a timer; it just armed one whose handler will fire in a different thread and interrupt a different stack. `signal.getsignal` is likewise callable anywhere. So "you can't arm an alarm off the main thread" is the wrong summary. The right one is: *you can arm it anywhere, and it will never interrupt the thread you armed it from unless that thread is the main thread.* ### What actually happens in the mixed case Suppose the main thread waits on `Thread.join()` while a worker performs a slow read, and the main thread arms a one-second alarm. The alarm fires, the handler raises in the main thread, and `join()` raises `TimeoutError`. That is genuinely useful — you have bounded your own *wait*. But the worker is untouched: it finishes its read later and, if it is not a daemon, it will still hold process exit open. You have a timeout on the observer, not on the work. ### Why threading.Timer is not a substitute `threading.Timer` is a `Thread` subclass that sleeps for an interval and then calls a function *in its own thread*; `cancel()` stops it if it has not fired yet. It works off the main thread, it works on Windows, and it needs no signal machinery. What it cannot do is interrupt anything: raising an exception inside the timer's own thread affects only that thread. It is a scheduler for a side effect — flip a flag, close a socket so a blocked reader sees an error, log a warning — never a cancellation primitive. That last variant is the practical bridge: a timer thread that *closes the resource* the worker is blocked on will unblock the worker, because the blocking call then fails with an OS error. You are still not cancelling the thread; you are removing what it was waiting on. ### The honest options for bounding off-main-thread work 1. **Use a real deadline on the call.** A socket's own timeout setter, a client library's timeout argument, a queue `get(timeout=...)`. Always first choice. 2. **Move the work into a child process** and terminate it when the deadline passes. This is the only mechanism that gives a hard kill, and it is what you fall back to for compiled work that never returns to the interpreter. 3. **Close the underlying resource from a watchdog** so the blocked call errors out. What is *not* available in CPython, at any version through 3.14, is cancelling or killing a running thread from outside. There is no `Thread.kill`, by design: a thread torn down at an arbitrary point leaves locks held and buffers half-written. Signals do not offer a back door to it, and that is the real content of this question.