Captured Variables in Closures and Async Blocks - Part Two

Unknown — Wed, 27 May 2026 00:00:00 +0000

This is Part Two of the "Captured Variables in Closures and Async Blocks" series, so make sure to check out Part One</a> if you haven't already, since Part Two builds directly on it.</p>

Recap from Part One</h2>

For reference, this is the implementation we arrived at in Part One</a>:</p>

pub</span> async</span> fn</span> write_with_backpressure</span>(</span></span>
    object_writer</span>:</span> impl</span> ObjectWriter</span> +</span> Send</span> +</span> '</span>static</span>,</span></span>
    permits</span>:</span> Arc</span><</span>Semaphore</span>></span>,</span></span>
    path</span>:</span> PathBuf</span>,</span></span>
    bytes</span>:</span> Bytes</span>,</span></span>
)</span> {</span></span>
    let</span> permit</span> =</span> permits</span>.</span>acquire_owned</span>(</span>)</span>.</span>await</span>.</span>unwrap</span>(</span>)</span>;</span></span>
    tokio</span>::</span>spawn</span>(</span>async</span> move</span> {</span></span>
        object_writer</span>.</span>write_object</span>(</span>path</span>,</span> bytes</span>)</span>.</span>await</span>;</span></span>
        drop</span>(</span>permit</span>)</span>;</span></span>
    }</span>)</span>;</span></span>
}</span></span></code></pre>
As mentioned in Part One</a>, this implementation still has a problem — it requires two redundant arguments for every write invocation: object_writer</code> and permits</code>. These instances will never change, so our API should ideally not require them to be specified on every call. We can solve this by creating a structure that holds the object_writer</code> and permits</code> context. This way, every call would only need to include what is unique to that particular invocation: the path</code> where the data will be stored and the bytes</code> that represent the data.</p>
As we saw in Part One</a>, closures and async blocks can be thought of as structs whose fields correspond to the captured variables. With this in mind, we can modify our implementation to first create a closure that captures object_writer</code> and permits</code> as its context, and then use this closure whenever we need to write an object.</p>
Ideal API</h2>
Let's start with our ideal function signature:</p>
pub</span> fn</span> create_writer_with_backpressure</span>(</span></span>
    object_writer</span>:</span> impl</span> ObjectWriter</span> +</span> Send</span> +</span> '</span>static</span>,</span></span>
    permits</span>:</span> Arc</span><</span>Semaphore</span>></span>,</span></span>
)</span> -></span> impl</span> AsyncFn</span>(</span>PathBuf</span>,</span> Bytes</span>)</span> {</span></span>
    ...</span></span>
}</span></span></code></pre>
which can be used by a caller like so:</p>
let</span> writer_with_backpressure</span> =</span> create_writer_with_backpressure</span>(</span>object_writer</span>,</span> permits</span>)</span>;</span></span>
</span>
//</span> Write multiple times (concurrently with backpressure) without needing to pass in either</span></span>
//</span> the `object_writer` or the `permits`</span></span>
writer_with_backpressure</span>(</span>"</span>/my_bucket/first_object</span>"</span>.</span>into</span>(</span>)</span>,</span> Bytes</span>::</span>from_static</span>(</span>b</span>"</span>1234</span>"</span>)</span>)</span>.</span>await</span>;</span></span>
writer_with_backpressure</span>(</span>"</span>/my_bucket/second_object</span>"</span>.</span>into</span>(</span>)</span>,</span> Bytes</span>::</span>from_static</span>(</span>b</span>"</span>5678</span>"</span>)</span>)</span>.</span>await</span>;</span></span></code></pre>
Our new function takes the context variables (object_writer</code> and permits</code>) and returns a function that takes as input the unique arguments needed for each write invocation (PathBuf</code></a> and Bytes</code></a>). We kept all argument types the same as in Part One</a> since we know those work, at least as a good starting point. We use AsyncFn</code></a> instead of Fn</code></a> as the return type because we know we'll eventually need to await</code> a permit, but the rest of the function signature is straightforward.</p>
This approach is considerably more ergonomic than our first implementation. It makes code more readable by requiring fewer arguments, and more closely aligns with our ideal design.</p>
Ideal Implementation</h2>
Next, let's implement our new function. For the most part, the body of our new function will be the same as the first implementation from Part One</a>, except that we'll wrap it in a closure that takes a PathBuf</code></a> and Bytes</code></a>, which becomes the return value, like so:</p>
pub</span> fn</span> create_writer_with_backpressure</span>(</span></span>
    object_writer</span>:</span> impl</span> ObjectWriter</span> +</span> Send</span> +</span> '</span>static</span>,</span></span>
    permits</span>:</span> Arc</span><</span>Semaphore</span>></span>,</span></span>
)</span> -></span> impl</span> AsyncFn</span>(</span>PathBuf</span>,</span> Bytes</span>)</span> {</span></span>
    move</span> |</span>path</span>:</span> PathBuf</span>,</span> bytes</span>:</span> Bytes</span>|</span> async</span> {</span></span>
        let</span> permit</span> =</span> permits</span>.</span>acquire_owned</span>(</span>)</span>.</span>await</span>.</span>unwrap</span>(</span>)</span>;</span></span>
        tokio</span>::</span>spawn</span>(</span>async</span> move</span> {</span></span>
            object_writer</span>.</span>write_object</span>(</span>path</span>,</span> bytes</span>)</span>.</span>await</span>;</span></span>
            drop</span>(</span>permit</span>)</span>;</span></span>
        }</span>)</span>;</span></span>
    }</span></span>
}</span></span></code></pre>
We added move</code> to the returned closure so that it takes ownership of object_writer</code> and permits</code>, ensuring our closure has the context it needs for future calls.</p>
Let's see what the compiler thinks about our new implementation:</p>
error[E0525]: expected a closure that implements the `AsyncFn` trait, but this closure only implements `AsyncFnOnce`</span></span>
 9 |   ) -> impl AsyncFn(PathBuf, Bytes) {</span></span>
   |        ---------------------------- the requirement to implement `AsyncFn` derives from here</span></span>
10 |       move |path: PathBuf, bytes: Bytes| async {</span></span>
   |       -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^</span></span>
   |       |</span></span>
   |  _____this closure implements `AsyncFnOnce`, not `AsyncFn`</span></span>
   | |</span></span>
11 | |         let permit = permits.acquire_owned().await.unwrap();</span></span>
   | |                      ------- closure is `AsyncFnOnce` because it moves the variable `permits` out of its environment</span></span>
12 | |         tokio::spawn(async move {</span></span>
13 | |             object_writer.write_object(path, bytes).await;</span></span>
14 | |             drop(permit);</span></span>
15 | |         });</span></span>
16 | |     }</span></span>
   | |_____- return type was inferred to be `{closure@src/second.rs:10:5: 10:39}` here</span></span></code></pre>
Let's break down this specific line:</p>

closure is AsyncFnOnce</code> because it moves the variable permits</code> out of its environment</p>
</blockquote>
As its name suggests, AsyncFnOnce</code></a> can only be called once because it consumes itself when called. In other words, the compiler determines that permits</code> is moved away on the first call, making it unavailable for any subsequent calls.</p>
Building on our Mental Model</h2>
Let's use the mental model we started building in Part One</a> to understand this compiler error. We can think of the captured variables for the returned closure as the following struct:</p>
struct</span> Closure</span> {</span></span>
    object_writer</span>:</span> impl</span> ObjectWriter</span> +</span> Send</span> +</span> '</span>static</span>,</span></span>
    permits</span>:</span> Arc</span><</span>Semaphore</span>></span>,</span></span>
}</span></span></code></pre>
The closure owns its captured variables because we used move</code>. This is by design, since the closure needs both object_writer</code> and permits</code> for its context. Next, let's look at the async block returned by the closure:</p>
struct</span> AsyncBlock</span> {</span></span>
    permits</span>:</span> &</span>Arc</span><</span>Semaphore</span>></span></span>
}</span></span></code></pre>
Using our mental model, we would expect the async block to capture permits</code> by reference since we didn't use the move</code> keyword. However, the following line from the compiler error hints that things may not be as we expect:</p>

closure is AsyncFnOnce</code> because it moves the variable permits</code> out of its environment.</p>
</blockquote>
In other words, permits</code> is moved out of Closure</code> even though we never explicitly used the move</code> keyword. If we examine how permits</code> is used inside the async block, we can see that permits.acquire_owned()</code></a> takes an Arc<Semaphore></code> by value, which implicitly moves permits</code> to satisfy that requirement. This explains the compiler error. Rephrased in terms of our mental model structs, the error would read:</p>

closure is AsyncFnOnce</code> because permits.acquire_owned()</code> in AsyncBlock</code> moves permits</code> from Closure</code> into AsyncBlock</code>.</p>
</blockquote>

  Tip</p>
  The `move` keyword is not always necessary for a captured variable to be moved into the closure struct. The compiler will move it implicitly if the body of the closure requires an owned instance.</div>
</div>
We can illustrate this problem using our mental model. The de-sugared closure implementation would look like the following:</p>
fn</span> closure_fn</span>(</span>closure</span>:</span> Closure</span>)</span> -></span> AsyncBlock</span> {</span></span>
    AsyncBlock</span> {</span></span>
        permits</span>:</span> closure</span>.</span>permits</span>,</span></span>
    }</span></span>
}</span></span></code></pre>
As discussed in Part One</a>, this view gives us a clearer picture of how captured variables are used and moved within a closure. Here, the Closure</code> argument must be passed by value because closure.permits</code> is moved into AsyncBlock</code>. This means closure_fn</code> can only be called once, since closure</code> is consumed at the end of the call.</p>
We could attempt to solve this by cloning permits</code> before calling acquire_owned</code>, like so:</p>
let</span> permit</span> =</span> permits</span>.</span>clone</span>(</span>)</span>.</span>acquire_owned</span>(</span>)</span>.</span>await</span>.</span>unwrap</span>(</span>)</span>;</span></span></code></pre>
however, this approach would result in lifetime errors later.</p>

  Tip</p>
  Async blocks should, in most cases, own the variables they capture. Because of the nature of asynchronous code, it is likely that an async block will outlive the scope in which the captured variables were defined, which Rust does not permit.</div>
</div>
Instead, we can clone permits</code> before</em> moving it into AsyncBlock</code>, like so:</p>
pub</span> fn</span> create_writer_with_backpressure</span>(</span></span>
    object_writer</span>:</span> impl</span> ObjectWriter</span> +</span> Send</span> +</span> '</span>static</span>,</span></span>
    permits</span>:</span> Arc</span><</span>Semaphore</span>></span>,</span></span>
)</span> -></span> impl</span> AsyncFn</span>(</span>PathBuf</span>,</span> Bytes</span>)</span> {</span></span>
    move</span> |</span>path</span>:</span> PathBuf</span>,</span> bytes</span>:</span> Bytes</span>|</span> {</span></span>
        let</span> permits_clone</span> =</span> permits</span>.</span>clone</span>(</span>)</span>;</span> //</span> this line is new</span></span>
        async</span> move</span> {</span></span>
            let</span> permit</span> =</span> permits_clone</span>.</span>acquire_owned</span>(</span>)</span>.</span>await</span>.</span>unwrap</span>(</span>)</span>;</span></span>
            tokio</span>::</span>spawn</span>(</span>async</span> move</span> {</span></span>
                object_writer</span>.</span>write_object</span>(</span>path</span>,</span> bytes</span>)</span>.</span>await</span>;</span></span>
                drop</span>(</span>permit</span>)</span>;</span></span>
            }</span>)</span>;</span></span>
        }</span></span>
    }</span></span>
}</span></span></code></pre>
which finally resolves the permits</code> compiler error. Using our mental model, we can now think of the async block as:</p>
struct</span> AsyncBlock</span> {</span></span>
    permits_clone</span>:</span> Arc</span><</span>Semaphore</span>></span></span>
}</span></span></code></pre>
and the closure implementation as:</p>
fn</span> closure_fn</span>(</span>closure</span>:</span> &</span>Closure</span>)</span> -></span> AsyncBlock</span> {</span></span>
    let</span> permits_clone</span> =</span> closure</span>.</span>permits</span>.</span>clone</span>(</span>)</span>;</span></span>
    AsyncBlock</span> {</span></span>
        permits_clone</span>,</span></span>
    }</span></span>
}</span></span></code></pre>
Note the use of a reference in the argument &Closure</code>. By taking a reference, closure_fn</code> can be called multiple times, which is required for it to implement AsyncFn</code>. Previously we couldn't use a reference because we needed to move closure.permits</code> into AsyncBlock</code>.</p>
Remaining Implementation Issues</h2>
Our next compiler error is the following:</p>
error[E0525]: expected a closure that implements the `AsyncFn` trait, but this closure only implements `AsyncFnOnce`</span></span>
 9 |   ) -> impl AsyncFn(PathBuf, Bytes) {</span></span>
   |        ---------------------------- the requirement to implement `AsyncFn` derives from here</span></span>
10 |       move |path: PathBuf, bytes: Bytes| {</span></span>
   |       -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^</span></span>
   |       |</span></span>
   |  _____this closure implements `AsyncFnOnce`, not `AsyncFn`</span></span>
   | |</span></span>
11 | |         let permits_clone = permits.clone();</span></span>
12 | |         async move {</span></span>
13 | |             let permit = permits_clone.acquire_owned().await.unwrap();</span></span>
14 | |             tokio::spawn(async move {</span></span>
15 | |                 object_writer.write_object(path, bytes).await;</span></span>
   | |                 ------------- closure is `AsyncFnOnce` because it moves the variable `object_writer` out of its environment</span></span>
...  |</span></span>
19 | |     }</span></span>
   | |_____- return type was inferred to be `{closure@src/second.rs:10:5: 10:39}` here</span></span></code></pre>
where the key line is:</p>

closure is AsyncFnOnce</code> because it moves the variable object_writer</code> out of its environment</p>
</blockquote>
This is similar to the error we solved for permits</code>. If we think of the captured variables of the spawned async block as:</p>
struct</span> SpawnedAsyncBlock</span> {</span></span>
    object_writer</span>:</span> impl</span> ObjectWriter</span> +</span> Send</span> +</span> '</span>static</span>,</span></span>
    path</span>:</span> PathBuf</span>,</span></span>
    bytes</span>:</span> Bytes</span>,</span></span>
    permit</span>:</span> OwnedSemaphorePermit</span>,</span></span>
}</span></span></code></pre>
we can reword the error in terms of our mental model structs as:</p>

closure is AsyncFnOnce</code> because it moves object_writer</code> from Closure</code> into SpawnedAsyncBlock</code> due to the move</code> keyword.</p>
</blockquote>
We can fix this using the same strategy we used for permits</code> — clone object_writer</code> before moving it into SpawnedAsyncBlock</code>, like so:</p>
pub</span> fn</span> create_writer_with_backpressure</span>(</span></span>
    object_writer</span>:</span> impl</span> ObjectWriter</span> +</span> Clone</span> +</span> Send</span> +</span> '</span>static</span>,</span></span>
    permits</span>:</span> Arc</span><</span>Semaphore</span>></span>,</span></span>
)</span> -></span> impl</span> AsyncFn</span>(</span>PathBuf</span>,</span> Bytes</span>)</span> {</span></span>
    move</span> |</span>path</span>:</span> PathBuf</span>,</span> bytes</span>:</span> Bytes</span>|</span> {</span></span>
        let</span> permits_clone</span> =</span> permits</span>.</span>clone</span>(</span>)</span>;</span></span>
        let</span> object_writer_clone</span> =</span> object_writer</span>.</span>clone</span>(</span>)</span>;</span> //</span> this line is new</span></span>
        async</span> move</span> {</span></span>
            let</span> permit</span> =</span> permits_clone</span>.</span>acquire_owned</span>(</span>)</span>.</span>await</span>.</span>unwrap</span>(</span>)</span>;</span></span>
            tokio</span>::</span>spawn</span>(</span>async</span> move</span> {</span></span>
                object_writer_clone</span>.</span>write_object</span>(</span>path</span>,</span> bytes</span>)</span>.</span>await</span>;</span></span>
                drop</span>(</span>permit</span>)</span>;</span></span>
            }</span>)</span>;</span></span>
        }</span></span>
    }</span></span>
}</span></span></code></pre>
Note that we also added a Clone</code> bound to object_writer</code>. With that, the compiler is satisfied.</p>
Recap</h2>
Let's analyze why our final implementation works by de-sugaring the closure and async blocks using our mental model. We can think of the closure implementation as:</p>
fn</span> closure_fn</span>(</span>closure</span>:</span> &</span>Closure</span>)</span> -></span> AsyncBlock</span> {</span></span>
    let</span> permits_clone</span> =</span> closure</span>.</span>permits</span>.</span>clone</span>(</span>)</span>;</span></span>
    let</span> object_writer_clone</span> =</span> closure</span>.</span>object_writer</span>.</span>clone</span>(</span>)</span>;</span></span>
    AsyncBlock</span> {</span></span>
        permits_clone</span>,</span></span>
        object_writer_clone</span>,</span></span>
    }</span></span>
}</span></span></code></pre>
The closure generates a new AsyncBlock</code> instance every time it's called, which is why it needs to clone permits</code> and object_writer</code> and move them into AsyncBlock</code>. Because closure_fn</code> only takes a reference to Closure</code>, it can be called multiple times — a requirement for our API.</p>
Then, the AsyncBlock</code> instance generated by the closure call gets passed by value into the following de-sugared async block implementation:</p>
fn</span> async_block_fn</span>(</span>async_block</span>:</span> AsyncBlock</span>)</span> {</span></span>
    let</span> permit</span> =</span> async_block</span>.</span>permits_clone</span>.</span>acquire_owned</span>(</span>)</span>.</span>await</span>.</span>unwrap</span>(</span>)</span>;</span></span>
    tokio</span>::</span>spawn</span>(</span></span>
        SpawnedAsyncBlock</span> {</span></span>
            object_writer_clone</span>:</span> async_block</span>.</span>object_writer_clone</span>,</span></span>
        }</span></span>
    )</span></span>
}</span></span></code></pre>
As we saw in Part One</a>, async block Future</code>s</a> can only be used once (unlike a closure, which can be called multiple times), which is why AsyncBlock</code> is passed by value. This also allows us to move async_block.object_writer_clone</code> into SpawnedAsyncBlock</code> without needing to clone it again.</p>
Lastly, the SpawnedAsyncBlock</code> instance gets passed by value into the following de-sugared implementation:</p>
fn</span> spawned_async_block_fn</span>(</span>spawned_async_block</span>:</span> SpawnedAsyncBlock</span>)</span> {</span></span>
    spawned_async_block</span></span>
        .</span>object_writer_clone</span></span>
        .</span>write_object</span>(</span>spawned_async_block</span>.</span>path</span>,</span> spawned_async_block</span>.</span>bytes</span>)</span></span>
        .</span>await</span>;</span></span>
    drop</span>(</span>spawned_async_block</span>.</span>permit</span>)</span>;</span></span>
}</span></span></code></pre>
Thank you for reading! I hope this two-part series has given you a clearer mental model for reasoning about ownership in Rust closures and async blocks.</p>

Captured Variables in Closures and Async Blocks - Part One

Unknown — Sat, 23 May 2026 00:00:00 +0000

The goal of this post is to develop a mental model around ownership of captured variables when using closures and async blocks. This mental model will help you understand when and why you need to use move</code></a>, as well as how to interpret compiler errors involving closures and async blocks. This post is divided into two parts.</p>

Problem Statement</h2>
Let's dive into this topic by implementing a somewhat common pattern. Consider a service like AWS S3, which has a limitation on how many requests it can process simultaneously — let's call that limit X</code>. To avoid errors on the X + 1</code> request, we'll implement a writer with backpressure: the writer will concurrently execute up to X</code> writes, but will wait before starting the X + 1</code> write until at least one pending write completes.</p>
Assume that we have an S3 object that implements the following trait:</p>

#</span>[</span>async_trait</span>]</span></span>
trait</span> ObjectWriter</span> {</span></span>
    async</span> fn</span> write_object</span>(</span>&</span>self</span>,</span> path</span>:</span> PathBuf</span>,</span> bytes</span>:</span> Bytes</span>)</span>;</span></span>
}</span></span></code></pre>First Implementation</h2>
Our first implementation could look something like the following:</p>
async</span> fn</span> write_with_backpressure</span>(</span></span>
    object_writer</span>:</span> impl</span> ObjectWriter</span>,</span></span>
    permits</span>:</span> Arc</span><</span>Semaphore</span>></span>,</span></span>
    path</span>:</span> &</span>Path</span>,</span></span>
    bytes</span>:</span> Bytes</span>,</span></span>
)</span> {</span></span>
    let</span> permit</span> =</span> permits</span>.</span>acquire</span>(</span>)</span>.</span>await</span>.</span>unwrap</span>(</span>)</span>;</span></span>
    tokio</span>::</span>spawn</span>(</span>async</span> {</span></span>
        object_writer</span>.</span>write_object</span>(</span>path</span>.</span>to_path_buf</span>(</span>)</span>,</span> bytes</span>)</span>.</span>await</span>;</span></span>
        drop</span>(</span>permit</span>)</span>;</span></span>
    }</span>)</span>;</span></span>
}</span></span></code></pre>
We're leveraging Semaphore</code>s</a>, which are well-suited to our scenario. Before spawning the write task, we attempt to acquire a semaphore permit, which only yields once a permit is available. Then, in the spawned task, we explicitly drop the permit</code> at the end to signal to the semaphore that a slot has freed up. We must reference permit</code> inside the async block to ensure it is captured — without this, permit</code> would be dropped in the outer scope immediately after the spawn, releasing the slot before the write completes. However, this implementation has several issues, including compiler errors we'll address shortly.</p>
Implementation Issues</h2>
In addition to path</code> and bytes</code> (the two arguments unique to each invocation), the caller must also pass object_writer</code> and permits</code>. These instances never change across calls, so it's redundant to pass them on every invocation. We'll address this in Part Two</a>.</p>
This code also fails to compile with the following errors:</p>
error[E0277]: `impl ObjectWriter` cannot be shared between threads safely</span></span>
 13 | /     tokio::spawn(async {</span></span>
 14 | |         object_writer.write_object(path.to_path_buf(), bytes).await;</span></span>
 15 | |         drop(permit);</span></span>
 16 | |     });</span></span>
    | |______^ `impl ObjectWriter` cannot be shared between threads safely</span></span>
    |</span></span>
    = note: required for `&impl ObjectWriter` to implement `Send`</span></span></code></pre>
Let's break down the last line of the error:</p>

required for &impl ObjectWriter</code> to implement Send</code></p>
</blockquote>
This requirement comes from tokio::spawn</code></a>. The future passed to spawn</code> must satisfy:</p>
Future</span> +</span> Send</span> +</span> '</span>static</span></span></code></pre>
Notice that the compiler refers to a reference</em> to impl ObjectWriter</code>, even though we started with an owned impl ObjectWriter</code>. Why?</p>
This is where we can start building a mental model around ownership and closures and async blocks.</p>
Building Our Mental Model</h2>
Closures and async blocks capture values by reference by default, unless the move</code> keyword is used. What does this mean for our example?</p>
For reference, here's our async block:</p>
async</span> {</span></span>
    object_writer</span>.</span>write_object</span>(</span>path</span>.</span>to_path_buf</span>(</span>)</span>,</span> bytes</span>)</span>.</span>await</span>;</span></span>
    drop</span>(</span>permit</span>)</span>;</span></span>
}</span></span></code></pre>
Our async block captures the following variables:</p>

object_writer</code></li>
path</code></li>
bytes</code></li>
permit</code></li>
</ul>
Because we did not</em> use the move</code> keyword, we can think of our async block as the following struct:</p>
struct</span> AsyncBlock</span><</span>'</span>a</span>,</span> '</span>b</span>,</span> '</span>c</span>,</span> '</span>d</span>></span> {</span></span>
    object_writer</span>:</span> &</span>'</span>a</span> impl</span> ObjectWriter</span>,</span></span>
    permits</span>:</span> &</span>'</span>b</span> Arc</span><</span>Semaphore</span>></span>,</span></span>
    path</span>:</span> &</span>'</span>c</span> Path</span>,</span></span>
    bytes</span>:</span> &</span>'</span>d</span> Bytes</span>,</span></span>
}</span></span></code></pre>
where all fields are references to the captured variables. This won't compile, but it's a useful mental model.</p>
Then, the async block implementation can be thought of as the body of the async block wrapped in a function that takes an AsyncBlock</code> instance:</p>
async</span> fn</span> async_block_fn</span><</span>...</span>></span>(</span>async_block</span>:</span> AsyncBlock</span><</span>...</span>></span>)</span> {</span></span>
    async_block</span></span>
        .</span>object_writer</span></span>
        .</span>write_object</span>(</span>async_block</span>.</span>path</span>,</span> async_block</span>.</span>bytes</span>)</span></span>
        .</span>await</span>;</span></span>
    drop</span>(</span>async_block</span>.</span>permit</span>)</span>;</span></span>
}</span></span></code></pre>
In this view, every captured variable is a field of our AsyncBlock</code> struct. When the async block is executed, the compiler passes a corresponding AsyncBlock<...></code> instance to async_block_fn</code> to access those captured values. While this is not the actual compiled output, it gives us a clearer picture of how captured variables are used within the async block. Note that an async block Future</code></a> can only be executed once, so in our mental model AsyncBlock</code> is always passed by value.</p>
This explains why the compiler sees a &impl ObjectWriter</code> rather than an impl ObjectWriter</code>: in our de-sugared view, async_block.object_writer</code> is a field of type &impl ObjectWriter</code>.</p>
Back to the compiler error (skipping some detail):</p>
error[E0277]: `impl ObjectWriter` cannot be shared between threads safely</span></span>
    ...</span></span>
    = note: required for `&impl ObjectWriter` to implement `Send`</span></span></code></pre>
How do we fix this? A reference to a type T</code> is Send</code> if T</code> is Sync</code>, so we could add a Sync</code> bound to object_writer</code>:</p>
pub</span> async</span> fn</span> write_with_backpressure</span>(</span></span>
    object_writer</span>:</span> impl</span> ObjectWriter</span> +</span> Sync</span>,</span></span>
    ...</span></span>
)</span> {</span></span>
    ...</span></span>
}</span></span></code></pre>
While this resolves the compiler error, it doesn't actually work because it introduces another:</p>
error[E0373]: async block may outlive the current function, but it borrows `object_writer`, which is owned by the current function</span></span></code></pre>
What we actually need is for the async block to take ownership of the captured values. We can do that with the move</code> keyword:</p>
pub</span> async</span> fn</span> write_with_backpressure</span>(</span></span>
    object_writer</span>:</span> impl</span> ObjectWriter</span>,</span></span>
    permits</span>:</span> Arc</span><</span>Semaphore</span>></span>,</span></span>
    path</span>:</span> &</span>Path</span>,</span></span>
    bytes</span>:</span> Bytes</span>,</span></span>
)</span> {</span></span>
    let</span> permit</span> =</span> permits</span>.</span>acquire</span>(</span>)</span>.</span>await</span>.</span>unwrap</span>(</span>)</span>;</span></span>
    tokio</span>::</span>spawn</span>(</span>async</span> move</span> {</span></span>
        object_writer</span>.</span>write_object</span>(</span>path</span>.</span>to_path_buf</span>(</span>)</span>,</span> bytes</span>)</span>.</span>await</span>;</span></span>
        drop</span>(</span>permit</span>)</span>;</span></span>
    }</span>)</span>;</span></span>
}</span></span></code></pre>
This still does not compile, but we are getting closer. Now we get:</p>
error: future cannot be sent between threads safely</span></span>
   ...</span></span>
note: captured value is not `Send`</span></span>
    |</span></span>
 29 |         object_writer.write_object(path.to_path_buf(), bytes).await;</span></span>
    |         ^^^^^^^^^^^^^ has type `impl ObjectWriter` which is not `Send`</span></span>
note: required by a bound in `tokio::spawn`</span></span></code></pre>
which can be resolved by adding a Send</code> bound to impl ObjectWriter</code>:</p>
    ...</span></span>
    object_writer</span>:</span> impl</span> ObjectWriter</span> +</span> Send</span></span>
    ...</span></span></code></pre>
More notably, the compiler now sees an impl ObjectWriter</code> rather than an &impl ObjectWriter</code>. This is a direct result of the move</code> keyword.</p>
Let's revisit our mental model with the move</code> variant. When the move</code> keyword is used on a closure or async block, the resulting struct owns the captured values rather than holding references to them. We can now think of our move</code> async block as:</p>
struct</span> AsyncBlock</span><</span>'</span>a</span>></span> {</span></span>
    object_writer</span>:</span> impl</span> ObjectWriter</span> +</span> Send</span>,</span></span>
    permits</span>:</span> Arc</span><</span>Semaphore</span>></span>,</span></span>
    path</span>:</span> &</span>'</span>a</span> Path</span>,</span></span>
    bytes</span>:</span> Bytes</span>,</span></span>
}</span></span></code></pre>
The field types exactly match the types of the captured variables. Note that AsyncBlock</code> does not own a Path</code></a> because the captured variable is of type &Path</code> — the async block takes ownership of the reference, not of the Path</code> itself.</p>
Even after adding Send</code>, the compiler is still not satisfied:</p>
error[E0310]: the parameter type `impl ObjectWriter + Send` may not live long enough</span></span>
   ...</span></span>
help: consider adding an explicit lifetime bound</span></span>
   |</span></span>
29 |     object_writer: impl ObjectWriter + Send + 'static,</span></span></code></pre>
which can be resolved by adding a 'static</code> bound to object_writer</code>.</p>

  Tip</p>
  Remember that `'static` used as a bound means that the type is an owned value (it doesn't have any references to other instances). It _doesn't_ mean that the variable will live for the duration of the program. I find this overloading of the `'static` keyword a bit unfortunate since it can be confusing.</div>
</div>
Adding Send</code> and 'static</code> as bounds to impl ObjectWriter</code> is not unreasonable — most types conform to these, so we are not painting ourselves into a corner. Once we add them, the compiler error around object_writer</code> goes away.</p>
Remaining Implementation Issues</h2>
Our implementation now looks like the following:</p>
pub</span> async</span> fn</span> write_with_backpressure</span>(</span></span>
    object_writer</span>:</span> impl</span> ObjectWriter</span> +</span> Send</span> +</span> '</span>static</span>,</span></span>
    permits</span>:</span> Arc</span><</span>Semaphore</span>></span>,</span></span>
    path</span>:</span> &</span>Path</span>,</span></span>
    bytes</span>:</span> Bytes</span>,</span></span>
)</span> {</span></span>
    let</span> permit</span> =</span> permits</span>.</span>acquire</span>(</span>)</span>.</span>await</span>.</span>unwrap</span>(</span>)</span>;</span></span>
    tokio</span>::</span>spawn</span>(</span>async</span> move</span> {</span></span>
        object_writer</span>.</span>write_object</span>(</span>path</span>.</span>to_path_buf</span>(</span>)</span>,</span> bytes</span>)</span>.</span>await</span>;</span></span>
        drop</span>(</span>permit</span>)</span>;</span></span>
    }</span>)</span>;</span></span>
}</span></span></code></pre>
However, there are still compiler errors. Starting with:</p>
error[E0597]: `permits` does not live long enough</span></span>
 30 |       permits: Arc<Semaphore>,</span></span>
    |       ------- binding `permits` declared here</span></span>
...</span></span>
 34 |       let permit = permits.acquire().await.unwrap();</span></span>
    |                    ^^^^^^^ borrowed value does not live long enough</span></span>
 35 | /     tokio::spawn(async move {</span></span>
 36 | |         object_writer.write_object(path.to_path_buf(), bytes).await;</span></span>
 37 | |         drop(permit);</span></span>
 38 | |     });</span></span>
    | |______- argument requires that `permits` is borrowed for `'static`</span></span>
 39 |   }</span></span>
    |   - `permits` dropped here while still borrowed</span></span>
    |</span></span>
note: requirement that the value outlives `'static` introduced here</span></span>
   --> /tokio-1.52.3/src/task/spawn.rs:176:28</span></span>
    |</span></span>
176 |         F: Future + Send + 'static,</span></span>
    |                            ^^^^^^^</span></span></code></pre>
This error mirrors the one we encountered with object_writer</code>. Just like impl ObjectWriter</code>, the permit</code> variable must be 'static</code> — that is, it must be an owned value with no references to other instances. Looking at the type SemaphorePermit</code></a>, the problem becomes clear:</p>
pub</span> struct</span> SemaphorePermit</span><</span>'</span>a</span>></span> {</span></span>
    sem</span>:</span> &</span>'</span>a</span> Semaphore</span>,</span></span>
    permits</span>:</span> u32</span>,</span></span>
}</span></span></code></pre>
It contains a reference to a Semaphore</code></a>, which makes it non-'static</code> and therefore incompatible with tokio::spawn</code></a>. Fortunately, the Tokio authors anticipated this, and provided an owned variant. We can switch to acquire_owned</code></a>:</p>
    ...</span></span>
    let</span> permit</span> =</span> permits</span>.</span>acquire_owned</span>(</span>)</span>.</span>await</span>.</span>unwrap</span>(</span>)</span>;</span></span>
    ...</span></span></code></pre>
which returns an OwnedSemaphorePermit</code></a> that is 'static</code>, since it contains no references:</p>
pub</span> struct</span> OwnedSemaphorePermit</span> {</span></span>
    sem</span>:</span> Arc</span><</span>Semaphore</span>></span>,</span></span>
    permits</span>:</span> u32</span>,</span></span>
}</span></span></code></pre>
The next error follows the same pattern. Path</code></a> is not 'static</code>, so we replace it with its owned counterpart, PathBuf</code></a>.</p>
With those changes, our implementation compiles without errors:</p>
pub</span> async</span> fn</span> write_with_backpressure</span>(</span></span>
    object_writer</span>:</span> impl</span> ObjectWriter</span> +</span> Send</span> +</span> '</span>static</span>,</span></span>
    permits</span>:</span> Arc</span><</span>Semaphore</span>></span>,</span></span>
    path</span>:</span> PathBuf</span>,</span></span>
    bytes</span>:</span> Bytes</span>,</span></span>
)</span> {</span></span>
    let</span> permit</span> =</span> permits</span>.</span>acquire_owned</span>(</span>)</span>.</span>await</span>.</span>unwrap</span>(</span>)</span>;</span></span>
    tokio</span>::</span>spawn</span>(</span>async</span> move</span> {</span></span>
        object_writer</span>.</span>write_object</span>(</span>path</span>,</span> bytes</span>)</span>.</span>await</span>;</span></span>
        drop</span>(</span>permit</span>)</span>;</span></span>
    }</span>)</span>;</span></span>
}</span></span></code></pre>
We still haven't addressed the redundancy noted earlier: object_writer</code> and permits</code> never change, yet must be passed on every call. We'll tackle that in Part Two</a>, which will give us another opportunity to explore closures and async blocks.</p>

Marco Herrera-Rendon

Captured Variables in Closures and Async Blocks - Part Two

Captured Variables in Closures and Async Blocks - Part One

Overcommitted Podcast — From Score to Source Code: Non-Traditional Careers & Rust

Marco Herrera-Rendon

Captured Variables in Closures and Async Blocks - Part Two

Captured Variables in Closures and Async Blocks - Part One

First Implementation</h2> Our first implementation could look something like the following:</p>

Overcommitted Podcast — From Score to Source Code: Non-Traditional Careers & Rust