tokio/task/blocking.rs
1use crate::task::JoinHandle;
2
3cfg_rt_multi_thread! {
4 /// Runs the provided blocking function on the current thread without
5 /// blocking the executor.
6 ///
7 /// In general, issuing a blocking call or performing a lot of compute in a
8 /// future without yielding is problematic, as it may prevent the executor
9 /// from driving other tasks forward. Calling this function informs the
10 /// executor that the currently executing task is about to block the thread,
11 /// so the executor is able to hand off any other tasks it has to a new
12 /// worker thread before that happens. See the [CPU-bound tasks and blocking
13 /// code][blocking] section for more information.
14 ///
15 /// Be aware that although this function avoids starving other independently
16 /// spawned tasks, any other code running concurrently in the same task will
17 /// be suspended during the call to `block_in_place`. This can happen e.g.
18 /// when using the [`join!`] macro. To avoid this issue, use
19 /// [`spawn_blocking`] instead of `block_in_place`.
20 ///
21 /// Note that this function cannot be used within a [`current_thread`] runtime
22 /// because in this case there are no other worker threads to hand off tasks
23 /// to. On the other hand, calling the function outside a runtime is
24 /// allowed. In this case, `block_in_place` just calls the provided closure
25 /// normally.
26 ///
27 /// Code running behind `block_in_place` cannot be cancelled. When you shut
28 /// down the executor, it will wait indefinitely for all blocking operations
29 /// to finish. You can use [`shutdown_timeout`] to stop waiting for them
30 /// after a certain timeout. Be aware that this will still not cancel the
31 /// tasks — they are simply allowed to keep running after the method
32 /// returns.
33 ///
34 /// [blocking]: ../index.html#cpu-bound-tasks-and-blocking-code
35 /// [`spawn_blocking`]: fn@crate::task::spawn_blocking
36 /// [`join!`]: macro@join
37 /// [`thread::spawn`]: fn@std::thread::spawn
38 /// [`shutdown_timeout`]: fn@crate::runtime::Runtime::shutdown_timeout
39 ///
40 /// # Examples
41 ///
42 /// ```
43 /// use tokio::task;
44 ///
45 /// # async fn docs() {
46 /// task::block_in_place(move || {
47 /// // do some compute-heavy work or call synchronous code
48 /// });
49 /// # }
50 /// ```
51 ///
52 /// Code running inside `block_in_place` may use `block_on` to reenter the
53 /// async context.
54 ///
55 /// ```
56 /// use tokio::task;
57 /// use tokio::runtime::Handle;
58 ///
59 /// # async fn docs() {
60 /// task::block_in_place(move || {
61 /// Handle::current().block_on(async move {
62 /// // do something async
63 /// });
64 /// });
65 /// # }
66 /// ```
67 ///
68 /// # Panics
69 ///
70 /// This function panics if called from a [`current_thread`] runtime.
71 ///
72 /// [`current_thread`]: fn@crate::runtime::Builder::new_current_thread
73 #[track_caller]
74 pub fn block_in_place<F, R>(f: F) -> R
75 where
76 F: FnOnce() -> R,
77 {
78 crate::runtime::scheduler::block_in_place(f)
79 }
80}
81
82cfg_rt! {
83 /// Runs the provided closure on a thread where blocking is acceptable.
84 ///
85 /// In general, issuing a blocking call or performing a lot of compute in a
86 /// future without yielding is problematic, as it may prevent the executor from
87 /// driving other futures forward. This function runs the provided closure on a
88 /// thread dedicated to blocking operations. See the [CPU-bound tasks and
89 /// blocking code][blocking] section for more information.
90 ///
91 /// Tokio will spawn more blocking threads when they are requested through this
92 /// function until the upper limit configured on the [`Builder`] is reached.
93 /// After reaching the upper limit, the tasks are put in a queue.
94 /// The thread limit is very large by default, because `spawn_blocking` is often
95 /// used for various kinds of IO operations that cannot be performed
96 /// asynchronously. When you run CPU-bound code using `spawn_blocking`, you
97 /// should keep this large upper limit in mind. When running many CPU-bound
98 /// computations, a semaphore or some other synchronization primitive should be
99 /// used to limit the number of computations executed in parallel. Specialized
100 /// CPU-bound executors, such as [rayon], may also be a good fit.
101 ///
102 /// This function is intended for non-async operations that eventually finish on
103 /// their own. If you want to spawn an ordinary thread, you should use
104 /// [`thread::spawn`] instead.
105 ///
106 /// Be aware that tasks spawned using `spawn_blocking` cannot be aborted
107 /// because they are not async. If you call [`abort`] on a `spawn_blocking`
108 /// task, then this *will not have any effect*, and the task will continue
109 /// running normally. The exception is if the task has not started running
110 /// yet; in that case, calling `abort` may prevent the task from starting.
111 ///
112 /// When you shut down the executor, it will attempt to `abort` all tasks
113 /// including `spawn_blocking` tasks. However, `spawn_blocking` tasks
114 /// cannot be aborted once they start running, which means that runtime
115 /// shutdown will wait indefinitely for all started `spawn_blocking` to
116 /// finish running. You can use [`shutdown_timeout`] to stop waiting for
117 /// them after a certain timeout. Be aware that this will still not cancel
118 /// the tasks — they are simply allowed to keep running after the method
119 /// returns. It is possible for a blocking task to be cancelled if it has
120 /// not yet started running, but this is not guaranteed.
121 ///
122 /// # When to use `spawn_blocking` vs dedicated threads
123 ///
124 /// `spawn_blocking` is intended for *bounded* blocking work that eventually finishes.
125 /// Each call occupies a thread from the runtime's blocking thread pool for the duration
126 /// of the task. Long-lived tasks therefore reduce the pool's effective capacity, which
127 /// can delay other blocking operations once the pool is saturated and work is queued.
128 ///
129 /// For workloads that run indefinitely or for extended periods (for example,
130 /// background workers or persistent processing loops), prefer a dedicated thread created with
131 /// [`thread::spawn`].
132 ///
133 /// As a rule of thumb:
134 /// - Use `spawn_blocking` for short-lived blocking operations
135 /// - Use dedicated threads for long-lived or persistent blocking workloads
136 ///
137 /// Note that if you are using the single threaded runtime, this function will
138 /// still spawn additional threads for blocking operations. The current-thread
139 /// scheduler's single thread is only used for asynchronous code.
140 ///
141 /// # Related APIs and patterns for bridging asynchronous and blocking code
142 ///
143 /// In simple cases, it is sufficient to have the closure accept input
144 /// parameters at creation time and return a single value (or struct/tuple, etc.).
145 ///
146 /// For more complex situations in which it is desirable to stream data to or from
147 /// the synchronous context, the [`mpsc channel`] has `blocking_send` and
148 /// `blocking_recv` methods for use in non-async code such as the thread created
149 /// by `spawn_blocking`.
150 ///
151 /// Another option is [`SyncIoBridge`] for cases where the synchronous context
152 /// is operating on byte streams. For example, you might use an asynchronous
153 /// HTTP client such as [hyper] to fetch data, but perform complex parsing
154 /// of the payload body using a library written for synchronous I/O.
155 ///
156 /// Finally, see also [Bridging with sync code][bridgesync] for discussions
157 /// around the opposite case of using Tokio as part of a larger synchronous
158 /// codebase.
159 ///
160 /// [`Builder`]: struct@crate::runtime::Builder
161 /// [blocking]: ../index.html#cpu-bound-tasks-and-blocking-code
162 /// [rayon]: https://docs.rs/rayon
163 /// [`mpsc channel`]: crate::sync::mpsc
164 /// [`SyncIoBridge`]: https://docs.rs/tokio-util/latest/tokio_util/io/struct.SyncIoBridge.html
165 /// [hyper]: https://docs.rs/hyper
166 /// [`thread::spawn`]: fn@std::thread::spawn
167 /// [`shutdown_timeout`]: fn@crate::runtime::Runtime::shutdown_timeout
168 /// [bridgesync]: https://tokio.rs/tokio/topics/bridging
169 /// [`AtomicBool`]: struct@std::sync::atomic::AtomicBool
170 /// [`abort`]: crate::task::JoinHandle::abort
171 ///
172 /// # Examples
173 ///
174 /// Pass an input value and receive result of computation:
175 ///
176 /// ```
177 /// use tokio::task;
178 ///
179 /// # async fn docs() -> Result<(), Box<dyn std::error::Error>>{
180 /// // Initial input
181 /// let mut v = "Hello, ".to_string();
182 /// let res = task::spawn_blocking(move || {
183 /// // Stand-in for compute-heavy work or using synchronous APIs
184 /// v.push_str("world");
185 /// // Pass ownership of the value back to the asynchronous context
186 /// v
187 /// }).await?;
188 ///
189 /// // `res` is the value returned from the thread
190 /// assert_eq!(res.as_str(), "Hello, world");
191 /// # Ok(())
192 /// # }
193 /// ```
194 ///
195 /// Use a channel:
196 ///
197 /// ```
198 /// use tokio::task;
199 /// use tokio::sync::mpsc;
200 ///
201 /// # async fn docs() {
202 /// let (tx, mut rx) = mpsc::channel(2);
203 /// let start = 5;
204 /// let worker = task::spawn_blocking(move || {
205 /// for x in 0..10 {
206 /// // Stand in for complex computation
207 /// tx.blocking_send(start + x).unwrap();
208 /// }
209 /// });
210 ///
211 /// let mut acc = 0;
212 /// while let Some(v) = rx.recv().await {
213 /// acc += v;
214 /// }
215 /// assert_eq!(acc, 95);
216 /// worker.await.unwrap();
217 /// # }
218 /// ```
219 #[track_caller]
220 pub fn spawn_blocking<F, R>(f: F) -> JoinHandle<R>
221 where
222 F: FnOnce() -> R + Send + 'static,
223 R: Send + 'static,
224 {
225 crate::runtime::spawn_blocking(f)
226 }
227}