>(())
});
let mut sum = 0;
while let Some(id) = receiver.recv().await {
sum += id;
}
producer.await??;
assert_eq!(sum, 6);
Ok(())
}
```
[View the tested source](https://github.com/robertdevore/rust.robertdevore.com/blob/main/examples/20_async.rs)
The macro builds a current-thread Tokio runtime. A producer task sends four values into a bounded channel. The consumer drains it, and the producer's sender is dropped at completion. The join handle reports whether the task failed and contains the producer's own result. In `await??`, the first `?` checks the task result; the second checks the producer's result.
## Limit queued work
A channel with capacity two creates backpressure: a send can wait for space. This bounds queued messages, not the size of each message or the total number of tasks elsewhere in the program. A production design must bound those separately.
Tokio schedules cooperatively. A long computation or blocking filesystem call inside a task can occupy the runtime thread and prevent other tasks from progressing. Async syntax alone does not make a function nonblocking. Use an appropriate async API, a dedicated worker, or `spawn_blocking` with a deliberate concurrency limit. A started blocking task generally cannot be aborted just by aborting its async handle.
## Check what cancellation leaves behind
Selecting between two futures drops a losing future in common patterns. Ask what progress it may have made and whether retrying loses or duplicates work. Tokio's `mpsc::Receiver::recv` has documented cancellation behavior useful in select loops. Other operations, such as reading an exact number of bytes, may have consumed partial input before cancellation.
A timeout is not rollback. Dropping a `JoinHandle` detaches the task; call `abort` when appropriate and await the handle to observe completion. Abortion takes effect when the task yields control, and destructors are part of cleanup. If cleanup needs async work, write a shutdown step that awaits it. Ordinary `Drop` cannot await.
## Exercise
Write a deterministic timeout test using Tokio's paused test clock. Make a receiver wait on an empty channel while a sender still exists; advance time and assert a timeout. Then drop the sender and assert that `recv` returns `None`. Use the repository's async tests as a reference after trying it.
Solution and acceptance check
Use `#[tokio::test(start_paused = true)]` with a current-thread test runtime and `tokio::time::timeout`. Paused time lets the runtime advance to the next timer when idle, avoiding fragile wall-clock sleeps. Retaining a sender prevents “channel closed” from winning first. Once the final sender is dropped, the receiver terminates. These are different outcomes and should have separate assertions.
` constrains how the pointee accessed through pointer `P` may be moved. It does not mean the pointer handle itself cannot move, and it does not automatically allocate anything.
For `T: Unpin`, moving the value does not violate a pinning invariant, so many pin restrictions become irrelevant. For a `!Unpin` value, safe APIs prevent operations that would violate the pin contract. The contract also involves destruction and storage validity; it is stronger than “do not call mem::swap right now”.
## Use safe constructors first
`pin!` pins a value in local storage. `Box::pin` owns a pinned allocation whose handle can move. Most async application code can use these or runtime helpers without implementing unsafe projection. Accessing a pinned struct's fields requires knowing which fields are structurally pinned. Do not use `get_unchecked_mut` just to bypass a compiler error.
### Run the example
```sh
cargo run --locked --example 21_pin
```
```rust
use std::{future::Future, pin::Pin};
trait Lookup {
fn get(&self) -> Pin + '_>>;
}
struct Fixed(usize);
impl Lookup for Fixed {
fn get(&self) -> Pin + '_>> {
Box::pin(async move { self.0 })
}
}
#[tokio::main(flavor = "current_thread")]
async fn main() {
let lookup = Fixed(42);
let service: &dyn Lookup = &lookup;
assert_eq!(service.get().await, 42);
}
```
[View the tested source](https://github.com/robertdevore/rust.robertdevore.com/blob/main/examples/21_pin.rs)
The interface returns a future in a pinned `Box`. The trait object hides its concrete type. Its lifetime is tied to `&self`, so it can borrow the service. The example uses a local executor and does not require `Send`. An API intended for movable spawned tasks may need `Send` on the returned future and appropriate bounds on the captured data.
## Calling async methods through trait objects
Native `async fn` in traits works on stable Rust for supported static-dispatch cases. That does not imply those methods can be dispatched directly through `dyn Trait`. Returning an explicitly erased future is a stable alternative, with allocation and indirection costs. The `async-trait` crate automates a related transformation; use it when you need this kind of interface.
**Intentionally fails on Rust 1.98.1.** Run `rustc --edition=2024 drills/async_dyn.rs` from the repository.
```rust
trait Fetch { async fn get(&self) -> usize; }
fn consume(_: &dyn Fetch) {}
fn main() {}
```
Actual compiler diagnostic · Rust 1.98.1
```text
error[E0038]: the trait `Fetch` is not dyn compatible
--> drills/async_dyn.rs:2:16
|
2 | fn consume(_: &dyn Fetch) {}
| ^^^^^^^^^ `Fetch` is not dyn compatible
|
note: for a trait to be dyn compatible it needs to allow building a vtable
for more information, visit
--> drills/async_dyn.rs:1:24
|
1 | trait Fetch { async fn get(&self) -> usize; }
| ----- ^^^ ...because method `get` is `async`
| |
| this trait is not dyn compatible...
= help: consider moving `get` to another trait
error: aborting due to 1 previous error
For more information about this error, try `rustc --explain E0038`.
```
Solution and acceptance check
The pointee stays in its allocation when the owning pointer moves. A concrete async method can return its compiler-generated future without the explicit box and vtable used here. Prefer the concrete method unless callers need to work with different implementations through one interface. Do not claim a speedup without measuring the relevant workload.
Solution and acceptance check
A valid policy closes admission, drops all producers' senders, drains already queued work, and awaits producer completion. A different policy may discard queued work, but the result must say it is incomplete. In the full-queue test, the consumer must keep making progress or cancellation must release the blocked send. Use deterministic synchronization rather than hoping a sleep creates the intended state.
Solution and acceptance check
The function returns borrows, not new owners of elements. Dropping a slice reference does not drop its elements. The original owner retains destruction responsibility. Forgetting a reference does not produce conflicting access by itself; the implementation does not rely on its destructor running. The tests check selected cases. The safety argument must cover every allowed safe caller.
Solution and acceptance check
Keep input bytes and loop counts identical, consume results so they cannot trivially disappear, and record toolchain/profile. The owned version allocates new message strings, but the timing difference may vary. A useful conclusion states the tested workload and uncertainty. If the difference is below noise, report that rather than selecting the fastest run.
Actual compiler diagnostic · Rust 1.98.1
```text
error[E0379]: functions in traits cannot be declared const
--> drills/const_trait.rs:1:17
|
1 | trait Compute { const fn compute(&self) -> usize; }
| ^^^^^-
| |
| functions in traits cannot be const
| help: remove the `const`
error: aborting due to 1 previous error
For more information about this error, try `rustc --explain E0379`.
```
Solution and acceptance check
A stable release note or merged stabilization record plus a successful minimal stable probe is strong evidence. A goal marked accepted, a nightly demo, or a merged RFC alone is insufficient. Preserve the older verification date in the research history and rerun affected compiler drills.
Solution and acceptance check
A slice can provide initialized byte storage and a valid length for the call. The wrapper can pass its pointer and length without transferring ownership. The contract must forbid retaining the pointer beyond the borrow unless a separate ownership protocol exists. The wrapper cannot prove arbitrary foreign code obeys that promise; implementation review and testing remain necessary.
Reference design and acceptance check
Represent completeness in the result type rather than silently discarding failures. Keep strict mode's behavior unchanged. A lenient mode should report both accepted and rejected counts and still fail on unreadable input. Discarding an oversized record requires scanning to a terminator while keeping storage bounded. Document whether a rejected final unterminated record is counted.
Solution and acceptance check
Accepting lowercase broadens the file grammar even if function signatures remain unchanged. Decide whether all case combinations are valid and whether messages remain untouched. Existing strict callers might rely on rejection, so consider compatibility in context. Release notes should state exactly which inputs now succeed and whether strict mode remains available.