Python gives no way to kill a threading.Thread — so how do you stop a running worker?

## Why the API is missing on purpose Threads share one address space and one set of locks. Terminating one at an arbitrary point would leave whatever it was holding held: a mutex never released, a dict half-updated, a file's buffer never flushed, a connection in an undefined protocol state. The surviving threads then deadlock or read corrupt state, and nothing in the process can recover. Runtimes that once offered asynchronous thread termination deprecated it for exactly this reason. Python simply never shipped it: there is no `Thread.kill()`, no `terminate()`, and `join()` is a *wait*, not a command. The consequence is that cancellation is a property of the **worker's own code**. A thread that never looks at a stop condition cannot be stopped, and no amount of cleverness at the call site changes that. ## The shape of a cancellable worker Take a warehouse pick-list builder that streams a 6,800-row batch through a background thread, and a deployment where shutdown must complete in a few seconds. The worker has to be written so it can be told to stop: 1. **A stop signal owned by the caller.** A `threading.Event` is the idiomatic one: `stop.set()` is visible to every thread, `stop.is_set()` is a cheap check, and `stop.wait(timeout)` doubles as an interruptible sleep. 2. **A check at a sensible granularity.** Once per row is cheap; once per 6,800-row batch is useless, because the check granularity *is* your shutdown latency. Pick a unit small enough that the worst-case wait is acceptable and large enough that the check is not the workload. 3. **Timeouts on every blocking call.** This is where most cooperative-cancellation attempts fail in production. A worker parked in a blocking read with no timeout will not look at the flag until the read returns, which may be never. Blocking channel reads, socket operations and lock acquisitions all take a timeout — use them, and treat the timeout expiry as "loop round and re-check the flag". 4. **A bounded wait at the caller.** `stop.set()`, then `t.join(timeout)`, then `if t.is_alive():` — because `join()` returns `None` and a timed join that expired is indistinguishable from a successful one otherwise. 5. **A decision about the worker that did not stop.** Log it with the thread's `name` and `native_id` so it can be found in system-level output, then choose: fail the shutdown loudly, or abandon it and accept the loss. Where the work is a stream of items rather than a loop over a range, a sentinel value pushed onto the worker's input channel is the same idea in another dress — it stops the worker at a clean boundary rather than mid-item. ## What does not work **Injecting an exception from outside.** CPython exposes a C-API function, reachable from Python through the foreign-function library, that schedules an exception in another thread. It is a trap. The exception is only delivered between bytecode instructions, so a thread inside a long-running C call — a compression pass, a big memory copy, a blocking syscall — does not see it until that call returns. It can arrive in the middle of a `try` block whose cleanup assumptions you never audited, or while a lock is held. And it can miss entirely if the target is in an `except` block that swallows it. It is a debugging tool at best, not a cancellation mechanism. **The daemon flag.** Marking the thread a daemon does not stop it; it only means the interpreter will not *wait* for it at exit, at which point the thread is frozen mid-instruction with no cleanup. That is abandonment, not cancellation, and it does nothing at all if you wanted to stop the worker while the process keeps running. **A bare unbounded `join()`.** It converts a stuck worker into a stuck shutdown, and the orchestrator's grace period then turns that into a hard kill of the whole process. ## When the work genuinely cannot be interrupted Some work is opaque: a native call that does not return until it is finished and offers no cancellation hook. Inside a thread there is nothing to be done — the thread cannot be pre-empted, and killing the process is the only lever. If such work must be cancellable, it belongs in a **separate process**, where the operating system can terminate it and the blast radius of a half-finished operation is bounded by process isolation. That choice is made when you design the worker, not during the incident: "can this be cancelled?" is a question about where the work runs, and by the time you need the answer it is too late to change it. ## Making it a habit Cancellability is a property you build in, like a timeout. Every long-running worker gets a stop event, every blocking call in it gets a timeout, and every shutdown path is bounded and logs what refused to stop. That is the whole discipline, and it is far cheaper than the alternative — discovering during a deploy that a worker holding a 6,800-row batch has no way to be told the process is going away.