# Tokio spawn_blocking abort does not stop a running task > Reproduce Tokio blocking-task cancellation with a start handshake, then stop the worker cooperatively and retain its JoinHandle until completion. Canonical URL: https://www.devobs.io/articles/understand-what-aborting-a-tokio-task-involving-spawn-blocking-can-stop-d-18650caf1b2c1651/ By: Nina Patel Published: 2026-09-11T12:48:02.931Z Updated: 2026-10-14T19:19:32.463Z Section: Architecture **Calling `abort()` on a started Tokio `spawn_blocking` task does not stop its closure.** If the task has not started, abort may prevent execution, but that is not guaranteed. To stop work that has already begun, design the blocking operation to return and keep its handle so you can observe completion. [Tokio's blocking-task contract](https://docs.rs/tokio/1.53.3/tokio/task/fn.spawn_blocking.html) The practical debugging question is: which event did you observe? An abort request, an async wrapper finishing, and the blocking worker finishing are different events. This example makes them visible without relying on a sleep to guess when the worker started. ## Reproduce abort after the worker starts The project below pins **Tokio 1.53.3**. It was compiled and run with **Rust 1.99.0 on aarch64-apple-darwin**. Its test checks that a worker acknowledges a probe sent after `abort()`, then returns normally after receiving `Stop`. This is a small lifecycle demonstration, not a throughput or shutdown-latency benchmark. Create `Cargo.toml`: ```toml [package] name = "blocking-stop-demo" version = "0.1.0" edition = "2021" [dependencies] tokio = { version = "=1.53.3", features = ["rt", "macros", "sync", "time"] } ``` Create `src/main.rs`: ```rust use std::{sync::mpsc, time::Duration}; use tokio::{sync::oneshot, time::timeout}; enum Command { Probe(oneshot::Sender<&'static str>), Stop, } async fn demonstrate() { let (commands, incoming) = mpsc::channel(); let (started_tx, started_rx) = oneshot::channel(); let mut worker = tokio::task::spawn_blocking(move || { let _ = started_tx.send(()); // Finite demo: at most ten receives, each with a one-second timeout. for _ in 0..10 { match incoming.recv_timeout(Duration::from_secs(1)) { Ok(Command::Probe(reply)) => { let _ = reply.send("still running"); } Ok(Command::Stop) => return "cooperative stop", Err(mpsc::RecvTimeoutError::Disconnected) => return "sender dropped", Err(mpsc::RecvTimeoutError::Timeout) => return "idle timeout", } } "message limit" }); timeout(Duration::from_secs(2), started_rx).await.unwrap().unwrap(); println!("worker started"); worker.abort(); println!("abort requested"); let (reply_tx, reply_rx) = oneshot::channel(); commands.send(Command::Probe(reply_tx)).unwrap(); let reply = timeout(Duration::from_secs(2), reply_rx).await.unwrap().unwrap(); assert_eq!(reply, "still running"); println!("probe after abort: {reply}"); commands.send(Command::Stop).unwrap(); // Borrow the handle so a timeout does not consume and drop it. let outcome = match timeout(Duration::from_secs(2), &mut worker).await { Ok(result) => result.unwrap(), Err(_) => { // Choosing to join here waits for actual completion. // A timeout alone would not stop an uncooperative worker. worker.await.unwrap() } }; assert_eq!(outcome, "cooperative stop"); println!("joined worker: {outcome}"); } #[tokio::main(flavor = "current_thread")] async fn main() { demonstrate().await; } ``` Run `cargo run`. The observed application output was: ```text worker started abort requested probe after abort: still running joined worker: cooperative stop ``` The first acknowledgment establishes that the closure has begun before the supervisor calls `abort()`. A probe is then sent **after** that call. Receiving its reply demonstrates that this worker processed a command after the abort request. Finally, joining returns the worker's own `"cooperative stop"` value. The example does not infer completion from an elapsed delay or from the abort method returning. There are deliberate escape paths: the loop handles at most ten messages, returns when its sender disappears, and has a one-second receive timeout. Rust documents `recv_timeout` as waiting for a message, channel disconnection, or the supplied timeout. These limits make the example finite; they are not a real-time scheduling guarantee. A sufficiently delayed supervisor can miss the worker’s one-second receive window and fail the diagnostic, so a timeout failure alone does not contradict the cancellation contract. [Rust receiver documentation](https://doc.rust-lang.org/std/sync/mpsc/struct.Receiver.html#method.recv_timeout) The `unwrap()` calls make failed assumptions visible in this diagnostic. In a service, handle startup failure, channel closure and join errors according to the request's failure policy instead of copying those panics into a handler. ## Keep the handle when the caller stops waiting The example passes `&mut worker` into `timeout`. The supervisor retains ownership of the join handle and can await it afterward. Passing the owned handle and abandoning that timeout would instead lose the ability to join through that handle: dropping a Tokio `JoinHandle` detaches its task. [JoinHandle ownership](https://docs.rs/tokio/1.53.3/tokio/task/struct.JoinHandle.html) A timeout limits waiting on its wrapped future. It does not add an interrupt mechanism to a synchronous closure. In this example the timeout branch deliberately resumes waiting for actual worker completion. For an uncooperative production operation, that subsequent wait could be indefinite. Decide explicitly whether your supervisor must wait, retain the handle for later collection, or give up observing that work. [Tokio timeout behavior](https://docs.rs/tokio/1.53.3/tokio/time/fn.timeout.html) The same ownership principle applies to a `tokio::select!` branch: awaiting `&mut JoinHandle` is documented as cancel safe, so another branch winning does not lose the task's output. That preserves an observation path; it does not stop the underlying operation. [JoinHandle cancel safety](https://docs.rs/tokio/1.53.3/tokio/task/struct.JoinHandle.html#cancel-safety) ## Separate the async wrapper from the blocking worker Suppose an async task calls `spawn_blocking`, owns its returned handle, and awaits it. Aborting the outer async task targets that wrapper. If its cancellation drops the inner handle, the blocking worker becomes detached. This follows from handle ownership and Tokio's documented drop behavior; completing the outer join does not establish that the separate blocking worker has finished. [JoinHandle documentation](https://docs.rs/tokio/1.53.3/tokio/task/struct.JoinHandle.html) A useful supervisor design keeps the blocking handle outside a disposable request wrapper, alongside the application's stop channel. Then request cancellation can ask the worker to finish while the supervisor retains responsibility for collecting its result. The sample uses exactly that ownership shape, without an outer wrapper. | Operation | What it establishes | What it does not establish | |---|---|---| | Abort before a blocking closure starts | A cancellation request was made | Guaranteed prevention of execution | | Abort after the start acknowledgment | The request targets an already-started task | Closure interruption | | Send `Stop` | A command entered the channel | Worker receipt or completion | | Await the blocking handle successfully | That worker returned its result | Completion of other tasks it spawned | | Finish an async wrapper | That wrapper finished | Completion of separately spawned blocking work | The abort rows follow Tokio's blocking-task contract; the command and join rows explain the ownership and protocol in this example. [Blocking-task reference](https://docs.rs/tokio/1.53.3/tokio/task/fn.spawn_blocking.html) ## A stop command needs a place to be handled In the demonstration, the worker returns to `recv_timeout` after every command. If you replace the probe handler with a synchronous library call, the worker cannot inspect `Stop` until that call returns. A channel does not make arbitrary blocking code interruptible. Break your own computation into finite pieces when that is practical, and check the stop condition between pieces. For external operations, investigate that operation's own deadline or cancellation support. Distinguish graceful draining from immediate abandonment. If the channel contains work before `Stop`, define whether the worker processes those messages, discards them, or records partial results. Also define what happens if the supervisor disappears: this example treats channel disconnection as a reason to return. Those are application choices rather than Tokio cancellation guarantees. For a persistent processing loop, Tokio recommends a dedicated `std::thread` rather than occupying its blocking pool indefinitely. That changes where the work runs; it does not supply forced termination. [Workload placement guidance](https://docs.rs/tokio/1.53.3/tokio/task/fn.spawn_blocking.html#when-to-use-spawn_blocking-vs-dedicated-threads) ## Runtime shutdown is another waiting policy Ordinary runtime shutdown waits for started blocking tasks to finish. `shutdown_timeout` stops waiting after its limit, while unfinished blocking work can continue. `shutdown_background` is equivalent to a zero-duration shutdown timeout and can leave resources associated with those tasks running. Neither method's return proves that the worker released what it holds. [Runtime shutdown documentation](https://docs.rs/tokio/1.53.3/tokio/runtime/struct.Runtime.html#method.shutdown_timeout) For a shutdown path you can reason about, name all three steps: request cooperative exit, retain and join the worker, then finish runtime shutdown. If a deadline forces you to abandon the join, report that as unfinished work rather than a successful stop. ## Source references - - - - - - -