0xpluie

Rust's async/await: Why and How

2026-04-25T00:00:00+00:00

Why async in the first place</h3>
Before touching any Rust-specific detail, it is worth asking why async exists at all.
In synchronous code, when you issue an I/O operation, the thread that issued it simply stops and waits. If the request takes 100ms, that is 100ms of pure waste from the CPU's perspective, since the CPU has nothing to do on behalf of this thread. I/O-bound work like network requests, disk reads, or timers spends most of its time waiting for something external to complete. There is idle time to reclaim in this case.
One obvious solution is to spin up more OS threads and let the kernel interleave them. When one thread blocks on I/O, the kernel schedules another. This works, but it scales poorly. Each OS thread carries a stack measured in megabytes, every context switch pays the cost of a kernel transition, and the kernel's preemptive scheduler has no idea which threads are actually worth running next. For a server juggling thousands of concurrent connections, most of which are idle at any given moment, this is quite a overhead for a lot of threads that spend most of their time asleep.
async is the answer to this problem. Rather than asking the kernel to manage concurrency for us, we use non-blocking I/O APIs and schedule concurrent operations in user space. A single OS thread can host many logical tasks, each suspending itself at I/O boundaries so others can run. Context switches are just function calls. Per-task memory is kilobytes rather than megabytes. This is often called user-space concurrency.
There are two broad design axes for user-space concurrency. The first is cooperative vs preemptive scheduling: do tasks voluntarily yield at known points (coroutines), or can the runtime suspend them at any moment (green threads)? The second, within cooperative schedulers, is stackful vs stackless: does each task carry its own stack, or does the compiler rewrite task bodies into plain data structures that carry no stack at all? Rust picked cooperative and stackless, which is what `Future</code>s are.`

async fn and Future</h3> The async</code> keyword on a function is essentially syntactic sugar. These two are roughly equivalent. async fn fetch() -> String { // ... } fn fetch() -> impl Future<Output = String> { async { // ... } }</code></pre> Future</code> is a trait representing a value that is not yet ready but will eventually produce one. The trait itself looks like this. pub trait Future { type Output; fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output>; } pub enum Poll<T> { Ready(T), Pending, }</code></pre> The important thing to notice is that calling an async function does not run its body. It just hands you back a Future, which does nothing until something calls poll</code> on it. If you try to use the return value directly, the compiler will nudge you to .await</code> it. State machines and await</h3> When the compiler sees an async fn</code>, it transforms the body into a state machine. Every .await</code> inside the function becomes a potential yield point, and any local variable that needs to survive across a yield point is captured as a field in that state. This is exactly what "stackless" means in stackless coroutine. There is no separate stack allocated for the async function. Instead, the compiler figures out what needs to live across each yield point and bakes it into a struct. The state machine is just a plain value, and it is as big as its largest state. To make this concrete, consider: async fn work() -> u32 { let a = step_one().await; let b = step_two(a).await; a + b }</code></pre> The compiler generates something roughly like this. enum WorkState { Start, AwaitingOne { fut: StepOneFuture }, AwaitingTwo { a: u32, fut: StepTwoFuture }, Done, }</code></pre> Each .await</code> splits the function into another state. The local a</code> has to live across the second .await</code>, so it gets stored in the AwaitingTwo</code> variant. It is tempting to think .await</code> is what "runs" the future. It isn't. .await</code> is a yield point, not an execution engine. Desugared, it looks roughly like this. loop { match fut.poll(cx) { Poll::Ready(value) => break value, Poll::Pending => yield, } }</code></pre> So .await</code> asks the inner future whether it is done. If yes, take the value and move on. If not, propagate Pending</code> up to whoever called us, which propagates it up again, and so on. The state machine pauses at whichever await point produced the Pending</code>, and resumes from exactly that point next time it is polled. The Executor</h3> So where does the propagated Pending</code> finally stop? Async code has to bottom out somewhere. Something has to hold the top-level future, call poll</code> on it, and decide what to do when it returns Pending</code>. That something is the executor, and in practice the executor is bundled with an async runtime that also provides the low-level I/O building blocks. tokio is by far the most common choice in Rust, though others like async-std and smol exist. This is also why main</code> cannot be async</code> directly. Something non-async has to set up the runtime and block on the top-level future. #[tokio::main]</code> is a macro that does exactly that for you. #[tokio::main] async fn main() { run().await; } // roughly expands to: fn main() { let rt = tokio::runtime::Runtime::new().unwrap(); rt.block_on(async { run().await; }); }</code></pre> We won't go deeper into how the executor schedules tasks or wakes them up. The mental model we need from here on is simple. There is a top-level loop that holds our futures, and when we say "yield", this is the thing we yield back to. Combining flows: join and select</h3> Async alone is not useful. You need multiple flows to interleave, otherwise there is no idle time to reclaim. join!</code> and select!</code> are the simplest way to combine futures. join!</code> waits for all of its futures to complete and returns their results together. let (user, posts) = tokio::join!(fetch_user(id), fetch_posts(id));</code></pre> select!</code> waits for the first of several futures to complete and lets you branch on which one finished first. Common use cases are timeouts, cancellation, and listening on multiple channels at once. tokio::select! { result = fetch_user(id) => handle(result), _ = tokio::time::sleep(Duration::from_secs(5)) => timeout(), }</code></pre> Note that both of these combine multiple futures into a single bigger future. From the executor's point of view there is still just one task, and the interleaving happens inside the combined future. spawn: handing tasks to the executor</h3> tokio::spawn</code> is different. It registers a future as an independent task with the executor. let handle = tokio::spawn(async { do_something().await }); // ... do other work ... let result = handle.await.unwrap();</code></pre> The caller does not have to wait for it. The task lives on its own, gets scheduled independently, and if it panics, the panic is isolated rather than taking down whatever spawned it. You get a JoinHandle</code> back that you can .await</code> later if you want the result, or drop if you don't care. tokio's multi-threaded runtime keeps a pool of OS threads, usually one per core, and spawned tasks can be moved between them. That is where actual parallel execution comes from. async by itself gives you concurrency, and parallelism only shows up once the runtime has multiple threads to place tasks on. Because of this mobility, spawned futures have to be 'static</code> and Send</code>. The task might outlive its caller and might run on a different thread than the one that spawned it, so it cannot borrow anything from the caller's stack. Blocking inside async</h3> The executor drives one task at a time on each of its worker threads. When a task hits an await and returns Pending</code>, the worker moves on to another task. This only works because tasks cooperate by yielding at await points. Now consider what happens if you do this. async fn handler() { std::thread::sleep(Duration::from_secs(5)); // ... }</code></pre> std::thread::sleep</code> is a synchronous call that asks the OS to park the thread it runs on. There is no await here, so there is no yield. The worker thread sits frozen for five seconds, and every other task that happened to be scheduled on that thread waits with it. If you only have a few worker threads, a handful of these can stall a huge chunk of your server. The same applies to anything that blocks, including heavy computation that never hits an await. async fn handler(data: Vec<u8>) -> Hash { compute_expensive_hash(&data) // runs for 200ms, no awaits }</code></pre> No other task on this worker thread makes progress during those 200ms. The fix is tokio::spawn_blocking</code>. tokio keeps a separate thread pool specifically for blocking work, and spawn_blocking</code> moves your synchronous operation onto one of those threads. Meanwhile the async worker threads keep serving other tasks. async fn handler(data: Vec<u8>) -> Hash { tokio::task::spawn_blocking(move || { compute_expensive_hash(&data) }).await.unwrap() }</code></pre>Blocking mutex across await</h3> std::sync::Mutex</code> is fine in async code as long as you never hold it across an .await</code>. The moment you do, you have a subtle but real deadlock risk. Consider this. async fn handler(state: Arc<std::sync::Mutex<State>>) { let guard = state.lock().unwrap(); some_async_call().await; // still holding the lock guard.modify(); }</code></pre> When some_async_call().await</code> returns Pending</code>, the worker thread moves on to another task, while this task keeps holding the mutex. If that other task on the same worker tries to lock the same mutex, it calls std::sync::Mutex::lock</code>, which is a blocking operation. It does not yield. It parks the thread waiting for the lock. But the lock is held by our suspended task, which is sitting in the executor's queue waiting to be polled again, which will only happen when the worker thread is free, which will only happen when the lock is released. The worker is stuck waiting for the lock, and the lock is stuck waiting for the worker. Deadlock. The fix is tokio::sync::Mutex</code>. When you call its .lock().await</code> and the mutex is held, it yields instead of blocking the thread. The worker is free to run other tasks, including whichever one holds the lock, which eventually releases it and wakes us up. async fn handler(state: Arc<tokio::sync::Mutex<State>>) { let mut guard = state.lock().await; some_async_call().await; guard.modify(); }</code></pre> In short, use std::sync::Mutex</code> for short critical sections that contain no awaits (it is faster). Use tokio::sync::Mutex</code> when the critical section crosses an await point. Summary</h3> async exists to provide user-space concurrency, sidestepping the memory and context-switching overhead of OS threads for I/O-heavy workloads. Rust implements it as cooperative, stackless coroutines, exposed as the Future</code> trait.</li> async fn</code> desugars to a function returning impl Future</code>, and the body is compiled into a state machine whose states are the await points.</li> .await</code> is a yield point. It propagates Pending</code> up the chain until it reaches an executor that owns the top-level future. tokio is the standard choice.</li> join!</code> and select!</code> combine futures within a single task. spawn</code> promotes a future to an independent task, and the runtime's thread pool is what actually provides parallelism.</li> </ul> Reference</h3> Crust of Rust - async/await</a></li> Why async Rust?</a></li> </ul>

Static vs Dynamic Dispatch in Rust 2026-04-22T00:00:00+00:00 Why do we need dispatch?</h3> Say we want to write a function that returns the length of a string. The most straightforward version looks like this: fn strlen(s: String) -> usize { s.len() }</code></pre> This works, but it's quite rigid. What if I want to pass a &str</code>? Or a Cow<str></code>? I'd have to either convert every argument into a String</code> before calling, or write a bunch of overloads like strlen_str</code>, strlen_cow</code>, and so on. What we actually want is: "take anything that can be viewed as a string, and give me its length." The concrete type shouldn't matter. Only the capability matters. That's what dispatch is for. It lets us write one function over many types, and leaves the details of how to resolve the right behavior to the compiler. Static dispatch</h3> Here's a version of strlen</code> that accepts anything string-like: fn strlen(s: impl AsRef<str>) -> usize { s.as_ref().len() } // All of these work: // strlen("hello world!"); // strlen(String::from("hello world!")); // strlen(&some_string);</code></pre> The impl AsRef<str></code> syntax means "any type T</code> that implements AsRef<str></code>." It's syntactic sugar for a generic parameter with a trait bound, so the function above is equivalent to: fn strlen<T: AsRef<str>>(s: T) -> usize { s.as_ref().len() }</code></pre> So what does the Rust compiler actually do with this? It performs monomorphization. For every distinct type T</code> that we call strlen</code> with, the compiler stamps out a separate, specialized copy of the function. Call it with a &str</code> and a String</code> in the same program, and you end up with two functions in the final binary: one where T = &str</code>, another where T = String</code>, each with as_ref</code> inlined for that specific type. This is called static dispatch because which version of the function to call is decided entirely at compile time. The upside is speed. There's no indirection, and the compiler can inline aggressively. The downside is code bloat (every T</code> gets its own copy) and, more importantly, the fact that the type has to be known at compile time. When static dispatch isn't enough</h3> Now, suppose we want a collection of things that all implement some trait, and we want to iterate over them: trait Greet { fn greet(&self); } struct English; struct Korean; impl Greet for English { fn greet(&self) { println!("Hello!"); } } impl Greet for Korean { fn greet(&self) { println!("안녕!"); } } // What type goes here? let greeters: Vec<???> = vec![English, Korean];</code></pre> We can't write Vec<impl Greet></code> or Vec<T: Greet></code> here. A Vec</code> holds elements of a single type, and monomorphization would need to pick one concrete T</code>. But English</code> and Korean</code> are different types, so static dispatch can't help us. What we want is to say "a vector of some greeters, where each element might be a different concrete type, and I'll figure out which greet</code> to call at runtime." That's dynamic dispatch, and Rust spells it with the dyn</code> keyword: let greeters: Vec<dyn Greet> = vec![English, Korean]; // doesn't compile!</code></pre> Except this doesn't compile. The error will say something about dyn Greet</code> not having a known size at compile time. Which brings us to the next section. Sized, and why dyn Trait isn't</h3> Almost every type in Rust implements the Sized</code> marker trait automatically. It just means "the compiler knows how many bytes this takes up." Rust needs this information to put things on the stack, in structs, in Vec</code>s, everywhere. dyn Greet</code> is different. It means "some type that implements Greet</code>", but we don't know which type, so we can't know the size. English</code> might be zero bytes, Korean</code> might be 48 bytes, and a third implementer might be huge. dyn Greet</code> is unsized (!Sized</code>). The fix is to put it behind a pointer, because pointers themselves are always sized: let greeters: Vec<Box<dyn Greet>> = vec![ Box::new(English), Box::new(Korean), ]; for g in &greeters { g.greet(); }</code></pre> A &dyn Greet</code> works too, if you don't need ownership. So how does the compiler actually make g.greet()</code> call the right method? A Box<dyn Greet></code> (or &dyn Greet</code>) isn't a normal pointer. It's a fat pointer, two words wide: A pointer to the data itself (the English</code> or Korean</code> value on the heap).</li> A pointer to a vtable, a small static table of function pointers for this trait, generated once per (type, trait)</code> pair by the compiler.</li> </ul> When you call g.greet()</code>, the compiler emits code that looks up greet</code> in the vtable and calls it through that pointer. The actual concrete type is never known to the caller. Only the vtable entries are. Object-safe traits</h3> Not every trait can be turned into a dyn Trait</code> though. The requirements come directly from how vtables and fat pointers work. Once you've got that picture in your head, the rules basically derive themselves. You can't combine arbitrary traits behind one dyn</code>. Something like dyn Greet + Clone</code> isn't allowed in general, because the fat pointer only has room for one vtable pointer. If you want both, you have to define a new trait that requires both and use dyn</code> on that: trait GreetAndClone: Greet + Clone {}</code></pre> The exception is auto traits like Send</code> and Sync</code>. They don't have methods, so they don't need a vtable, which is why dyn Greet + Send</code> works. Associated types must be fixed. If a trait has type Item;</code>, the vtable has no way to carry that around, since types aren't runtime values. So you have to pin it down at the dyn</code> site: dyn Iterator<Item = u32> // ok dyn Iterator // not ok</code></pre> No methods that take self</code> by value, and no methods that return Self</code>. Taking self</code> by value requires knowing the size to move it, which we don't have. Returning Self</code> is even worse: the caller has no idea what type came back, so there's nothing useful they could do with it. No generic methods. As we've seen earlier, generic methods get monomorphized per type parameter, which would mean a vtable of unbounded size. You'd need one entry per T</code> the method could ever be called with, and the compiler has no way of knowing that up front. Any escape hatch?</h3> If only some methods of a trait violate these rules, you can opt them out of dynamic dispatch by adding a where Self: Sized</code> bound. Those methods then only exist for concrete types, and the rest of the trait remains object-safe. Iterator</code> does exactly this. It has a mountain of generic adapter methods (map</code>, filter</code>, collect</code>, ...), but they're all gated on Self: Sized</code>, which is why dyn Iterator<Item = T></code> is still supported. Summary</h3> Static dispatch (impl Trait</code> or generics) resolves everything at compile time via monomorphization. It's fast, but the type has to be known up front.</li> Dynamic dispatch (dyn Trait</code> behind a pointer) uses a fat pointer with a vtable to resolve calls at runtime, which is flexible enough for runtime type choice.</li> The object-safety rules for dyn Trait</code> are just whatever the vtable + fat-pointer representation can physically support.</li> </ul> Reference</h3> This post is heavily based on Jon Gjengset's Crust of Rust: Dispatch and Fat Pointers</a> session. If you're interested in this topic, watching the original video is highly recommended. Your Code Doesn't Run the Way You Read It 2026-04-22T00:00:00+00:00 I recently watched a stream on Rust's std::sync::atomic</code> module, and honestly, most of it went over my head on the first pass. But there's one insight from the session I think it's worth sharing even as I'm still wrapping my head around the rest. A test that shouldn't fail</h3> Here's a simplified version of a test case from the stream. Ignore the Ordering</code> argument for now. #[test] fn at_least_one_is_non_zero() { loom::model(|| { let x: &'static _ = Box::leak(Box::new(AtomicUsize::new(0))); let y: &'static _ = Box::leak(Box::new(AtomicUsize::new(0))); let t1 = spawn(move || { x.store(1, Ordering::Relaxed); y.load(Ordering::Relaxed) }); let t2 = spawn(move || { y.store(1, Ordering::Relaxed); x.load(Ordering::Relaxed) }); let r1 = t1.join().unwrap(); let r2 = t2.join().unwrap(); assert!(r1 == 1 || r2 == 1); }); }</code></pre> Two threads, each writing 1</code> to their own variable and then reading the other's. Intuitively, at least one of the reads should see 1</code>, right? There are only four lines of code across the two threads, and no matter how you interleave them, one thread's store</code> must happen before the other thread's load</code>. So r1 == 0 && r2 == 0</code> looks impossible. But the test fails</h3> Yet loom</code> happily finds an execution where both reads return 0</code>. How is that possible? What's actually going on</h3> The short answer is that Relaxed</code> atomic operations provide almost no ordering guarantees across different memory locations. They say nothing about how operations on different locations are observed by other threads. In the execution loom</code> finds, you can think of it like this: on real hardware, each CPU core has a store buffer. When t1</code> executes x.store(1)</code>, the write might sit in t1</code>'s store buffer for a while before it's flushed to memory that t2</code> can see. Meanwhile, t1</code> goes ahead and does y.load()</code>, which reads from the memory where t2</code>'s write to y</code> hasn't landed yet either. Symmetrically for t2</code>. Both threads end up reading the initial 0</code>, because neither store has been made visible to the other thread at the time of the load. Note that this doesn't mean r1</code> and r2</code> are always both 0—it's just that there's a legitimate execution order that allows it to happen. (And loom</code> is a testing tool that searches through all such possible orderings for you.) Sequential execution is a fiction</h3> Here's where it gets interesting. Stepping back from the specifics of atomics, what this really illustrates is something more fundamental about how programs execute. We tend to read code top-to-bottom and imagine it runs that way. But underneath, your program isn't really a sequence. It's a dependency graph. Nodes are operations, edges are 'this must happen before that.' Any execution order that respects the edges is a valid execution, and if two nodes have no edge between them, there's simply no fact of the matter about which one runs first. Most of the time, we don't notice this. The compiler, the CPU, and the language runtime work hard to preserve the illusion of sequential execution. In single-threaded code, the illusion is near-perfect. But the cost of maintaining that illusion across threads is enormous, so at the boundary of concurrency, the curtain gets pulled back and the graph shows through. That's what's happening in our test. t1</code>'s store</code> and t2</code>'s load</code> aren't connected by any edge in the graph. Nothing in the Relaxed</code> ordering forces one to happen before the other, and nothing forces their effects to propagate in any particular order. So the runtime is free to pick any ordering it likes, including the one where both threads miss each other's writes. So how do we fix it?</h3> So how do we make the test pass? We add edges to the graph. That's what the Ordering</code> parameter is for. x.store(1, Ordering::SeqCst); y.load(Ordering::SeqCst)</code></pre> Swapping Relaxed</code> for SeqCst</code> (sequentially consistent) is the heaviest hammer in the box. It says: all SeqCst</code> operations across all threads must appear to happen in some single global order that every thread agrees on. Under this constraint, the "both reads return 0" execution becomes impossible. If there's a global order, then either x.store</code> comes before x.load</code> or y.store</code> comes before y.load</code> (or both), and whichever it is, the corresponding load must see 1</code>. There are weaker (and cheaper) orderings too: Acquire</code>, Release</code>, AcqRel</code>. It's out of this post's scope to unpack what each of them does exactly (and honestly it's out of my brain's scope too). The general shape is: each ordering level is a different set of edges you're willing to pay for, and picking the right one is about the minimal set of edges your invariants actually require. Summary</h3> A program isn't the sequential text you read. It's a graph, and concurrency is just where that truth stops being hideable. Ordering</code> is how you declare, precisely and at a cost, which edges of that graph actually matter to you. </li> Don't go deep into the lock-free world unless you really have to. The stream was more than enough to scare me off. </li> </ul> Reference</h3> As always, this post is heavily based on Jon Gjentset's Crust of Rust — Atomics and Memory Ordering</a> session. If you are interested in this topic, watching the original video is highly recommended. Building a Rust Channel from Scratch 2026-04-19T00:00:00+00:00 Channels are a fundamental concurrency primitive in Rust, allowing threads to communicate safely by passing messages. At a high level, the concept is simple: senders transmit data, and receivers consume it. But what actually happens under the hood? In this post, we will demystify the inner workings of channels by implementing a basic Multi-Producer, Single-Consumer (MPSC) channel from scratch. Afterward, we'll briefly explore some of the common channel flavors you might encounter in the wild. Sender and Receiver</h3> The basic interface is fairly straightforward. A channel requires a sender and a receiver, each equipped with send</code> and recv</code> methods respectively. pub fn channel<T>() -> (Sender<T>, Receiver<T>) { // TODO } #[cfg(test)] mod tests { use super::*; #[test] fn ping_pong() { let (mut tx, mut rx) = channel(); tx.send(42); assert_eq!(rx.recv(), Some(42)); } }</code></pre>Mutex</h3> The sender and receiver need to share a queue where senders can push data and the receiver can pop it. We will wrap the inner data with an Arc</code> and a Mutex</code> to safely share the queue across threads. Note that using #[derive(Clone)]</code> on Sender</code> would unnecessarily impose a T: Clone</code> bound, so we will implement the Clone</code> trait manually. pub struct Sender<T> { inner: Arc<Inner<T>>, } impl<T> Clone for Sender<T> { fn clone(&self) -> Self { Sender { inner: Arc::clone(&self.inner), } } } impl<T> Sender<T> { pub fn send(&mut self, t: T) { let queue = self.inner.queue.lock().unwrap(); queue.push_back(t); } } pub struct Receiver<T> { inner: Arc<Inner<T>>, } impl<T> Receiver<T> { pub fn recv(&mut self) -> Option<T> { let queue = self.inner.queue.lock().unwrap(); queue.pop_front() } } struct Inner<T> { queue: Mutex<VecDeque<T>>, } pub fn channel<T>() -> (Sender<T>, Receiver<T>) { let inner = Inner { queue: Mutex::default(), }; let inner = Arc::new(inner); ( Sender { inner: inner.clone(), }, Receiver { inner: inner.clone(), }, ) }</code></pre> This looks reasonable, but recv currently returns an Option<T></code> because it immediately returns None</code> if the queue is empty. The typically expected behavior, however, is for the receiver to block and wait until an item becomes available. Constantly polling for a new item is inefficient and wastes CPU cycles, so what's a better approach? Condvar</h3> This is where Condvar</code> comes in. We can pair a condition variable with our mutex to signal the availability of new items. The receiver can now be efficiently notified when a new item arrives without wasting any resources, as long as the senders emit a notification when they push an item. struct Inner<T> { queue: Mutex<VecDeque<T>>, available: Condvar } impl<T> Sender<T> { pub fn send(&mut self, t: T) { let queue = self.inner.queue.lock().unwrap(); queue.push_back(t); drop(queue); self.inner.available.notify_one(); } } impl<T> Receiver<T> { pub fn recv(&mut self) -> T { let queue = self.inner.queue.lock().unwrap(); loop { match queue.pop_front() { Some(t) => return t, None => { queue = self.inner.available.wait(queue).unwrap(); } } } } }</code></pre> You might wonder why a loop is necessary in recv if the condition variable wakes up the thread only when an item is added. In reality, threads can experience "spurious wakeups" - waking up without a clear reason. Thus, wrapping the wait inside a loop ensures we actually have an item before proceeding. Dangling Receiver</h3> So far, everything seems fine. Senders send data, and the receiver waits for and receives it. But what happens if all senders are dropped while the receiver is still waiting for new messages? #[test] fn closed_tx() { let (tx, mut rx) = channel::<()>(); drop(tx); // Can this end? let _ = rx.recv(); }</code></pre> Our current implementation will block forever in this scenario. To fix this, it would be a good idea to track the number of active senders. pub struct Sender<T> { shared: Arc<Shared<T>>, } impl<T> Clone for Sender<T> { fn clone(&self) -> Self { let mut inner = self.shared.inner.lock().unwrap(); inner.senders += 1; drop(inner); Sender { shared: Arc::clone(&self.shared), } } } impl<T> Drop for Sender<T> { fn drop(&mut self) { let mut inner = self.shared.inner.lock().unwrap(); inner.senders -= 1; let was_last = inner.senders == 0; drop(inner); if was_last { self.shared.available.notify_one(); } } } impl<T> Sender<T> { pub fn send(&mut self, t: T) { let mut inner = self.shared.inner.lock().unwrap(); inner.queue.push_back(t); drop(inner); self.shared.available.notify_one(); } } pub struct Receiver<T> { shared: Arc<Shared<T>>, } impl<T> Receiver<T> { pub fn recv(&mut self) -> Option<T> { let mut inner = self.shared.inner.lock().unwrap(); loop { match inner.queue.pop_front() { Some(t) => return Some(t), None if inner.senders == 0 => return None, None => { inner = self.shared.available.wait(inner).unwrap(); } } } } } struct Inner<T> { queue: VecDeque<T>, senders: usize, } struct Shared<T> { inner: Mutex<Inner<T>>, available: Condvar, } pub fn channel<T>() -> (Sender<T>, Receiver<T>) { let inner = Inner { queue: VecDeque::default(), senders: 1, }; let shared = Shared { inner: Mutex::new(inner), available: Condvar::new(), }; let shared = Arc::new(shared); ( Sender { shared: shared.clone(), }, Receiver { shared: shared.clone(), }, ) }</code></pre> Notice how we now manage the number of senders alongside the queue inside the mutex. The receiver will return None</code> if there are no more senders available instead of blocking indefinitely. Single Consumer Optimization</h3> Although our goal was an MPSC channel, notice that the underlying logic for Sender</code> and Receiver</code> currently doesn't enforce this. In fact, our implementation could easily support multiple receivers as well. How can we take advantage of the single-consumer constraint? Since there's only one receiver, it is perfectly safe to grab all available items from the shared queue at once, rather than taking them one by one. After all, there's no one else to consume the items! This is a significant optimization: the receiver only needs to acquire the shared mutex when its local buffer is completely empty. pub struct Receiver<T> { shared: Arc<Shared<T>>, buffer: VecDeque<T>, } impl<T> Receiver<T> { pub fn recv(&mut self) -> Option<T> { if let Some(t) = self.buffer.pop_front() { return Some(t); } let mut inner = self.shared.inner.lock().unwrap(); loop { match inner.queue.pop_front() { Some(t) => { std::mem::swap(&mut self.buffer, &mut inner.queue); return Some(t); } None if inner.senders == 0 => return None, None => { inner = self.shared.available.wait(inner).unwrap(); } } } } }</code></pre> Notice how we swap the entire queue intto the local buffer if an item is available. Lock contention can be drastically reduced in certain conditions because the mutex is only acquired when this buffer runs out. Alternative Implementations</h3> Our implementation relied on Mutex</code>, Condvar</code>, and VecDeque</code>. Production-ready channel implementations might use a LinkedList</code> instead of a VecDeque</code> to avoid allocation overhead during resizing, or employ lock-free data structures using atomic operations instead of Mutex</code> and Condvar</code>. We won't delve into those advanced techniques in this post. Channel Flavors</h3> Before wrapping up, it's worth mentioning the basic flavors of channels that are widely used in Rust. Unbounded Channels: A channel with infinite capacity. send()</code> never blocks. Our implementation is an example of an unbounded channel.</li> Bounded Channels: A channel with a fixed capacity limit. send()</code> will block if the channel is full, providing natural back-pressure.</li> Rendezvous Channels: A bounded channel with zero capacity. It forces the sender and receiver to meet at the exact same time to hand off data, mostly used for thread synchronization.</li> Oneshot Channels: A channel designed to send exactly one message.</li> </ul> Channel implementations can support these flavors through distinct types or by modifying the runtime behavior of a single type. Reference</h3> This post is heavily based on Jon Gjentset's Crust of Rust — Channels</a> session. Code snippets are also taken from the original session. If you are interested in this topic, watching the original video is highly recommended. Making Sense of Send and Sync in Rust 2026-04-18T00:00:00+00:00 It's common to encounter Send + Sync</code> bounds when working with various Rust codebases. But what do they actually mean, and how do they work under the hood? When exactly is a type Send</code> or Sync</code>, and when is it not? Send</h3> A type is Send</code> if it is safe to send, or transfer ownership to another thread. pub unsafe auto trait Send {}</code></pre> Note that implementing Send</code> doesn't provide any special methods or behavior; rather, it acts as a marker indicating that the type satisfies a specific safety condition. The auto</code> keyword means the compiler will automatically implement Send</code> for a type if all of its inner fields are also Send</code>. Thus, it's quite rare (and requires unsafe</code>) to manually implement Send</code>. Doing so means you're explicitly telling the compiler that a type is safe to send across threads, even if it contains non-Send</code> fields. (Conversely, explicitly opting out with !Send</code> is also rare but useful when you want to enforce thread-locality.) Sync</h3> A type T</code> is Sync</code> if and only if its shared reference &T</code> is Send</code>. In other words, a type is Sync</code> if it is safe to share references across threads. It's an auto marker trait like Send</code>. pub unsafe auto trait Sync {}</code></pre>!Send + Sync</h3> Most primitive types we can think of are both Send</code> and Sync</code>, so let's explore some examples that lack at least one of these properties. If a type is Sync</code> but not Send</code>, it means you can safely share references to it across threads, but you cannot transfer its ownership to another thread. A classic example is std::sync::MutexGuard</code>. impl<T: ?Sized> !Send for std::sync::MutexGuard<'_, T> impl<T: ?Sized + Sync> Sync for std::sync::MutexGuard<'_, T></code></pre> MutexGuard</code> is not Send</code> because some operating systems require mutex locks to be released by the exact same thread that acquired them. However, this doesn't prevent the type from being Sync</code>. Sharing references is perfectly fine as long as the ownership (and thus the responsibility to release the lock) remains on the original thread. The T: Sync</code> bound is required because you can obtain a &T</code> from a &MutexGuard</code> via Deref</code>. Send + !Sync</h3> It might sound a bit weird for a type to be Send</code> but not Sync</code>, but we already saw some examples of this in the previous post</a>. We talked about how Cell</code> provides interior mutability through shared references, and how that is only safe in a single-thread context. If we can share references of Cell</code> across threads, multiple threads could concurrently mutate the inner value, breaking the safety invariant. However, transferring ownership of the Cell</code> itself to another thread is completely fine (provided the inner value is Send</code>), because it guarantees that only one thread can access it at a time. The same logic applies to RefCell</code> as well. impl<T> Send for Cell<T> where T: Send + ?Sized, impl<T> Send for RefCell<T> where T: Send + ?Sized, impl<T> !Sync for Cell<T> where T: ?Sized, impl<T> !Sync for RefCell<T> where T: ?Sized,</code></pre>!Send + !Sync</h3> Given our discussion on Cell</code> and RefCell</code>, you might wonder about Rc</code>. Rc</code> satisfies neither property because its internal reference counter is not atomic. If Rc</code> were Sync</code>, multiple threads could borrow it and call clone()</code> concurrently, leading to data races on the internal reference count. If Rc</code> were Send</code>, you could clone an Rc</code> and send the cloned instance to another thread, which would again allow concurrent, non-atomic modifications to the shared reference count. impl<T, A> !Send for Rc<T, A> where A: Allocator, T: ?Sized, impl<T, A> !Sync for Rc<T, A> where A: Allocator, T: ?Sized,</code></pre>Reference</h3> This post is heavily based on Jon Gjentset's Crust of Rust — Send, Sync, and their implementors</a> session. Code snippets are taken from the official std documents. If you are interested in this topic, watching the original video is highly recommended. Aliasing, Mutability, Containers and Pointers 2026-04-17T00:00:00+00:00 T, &mut T, &T</h3> In Rust, any arbitrary type T</code> can either be owned as T</code> itself, or used in two forms of aliases: &mut T</code> and &T</code>. T</code>: the owned value itself</li> &mut T</code>: a mutable reference with write access to T</code></li> &T</code>: an immutable reference that allows reading but not modification</li> </ul> Aliasing NAND Mutability</h3> Rust's borrow checker enforces a rule known as Aliasing NAND Mutability to guarantee safety at compile time. That is: While a &mut T</code> exists (Mutability = 1), no other reference to T</code> may exist (Aliasing = 0).</li> While a &T</code> exists (Aliasing = 1), no &mut T</code> may exist (Mutability = 0).</li> </ul> Containers & Pointers</h3> In practice, however, strictly adhering to these constraints is not always straightforward. There are cases where mutation is needed — and can be proven safe — even when multiple aliases exist, or where shared references bound to a specific scope and lifetime make it difficult to express data that is jointly owned and accessed from multiple places. To accommodate these scenarios while extending the safety guarantees in a flexible way, Rust provides a variety of containers and pointers. Each of them can be examined from two angles: In what situations is it useful?</li> How does it still uphold safety?</li> </ul> Cell</h3> Cell<T></code> is a container that enables interior mutability in a single-threaded context — allowing multiple references to coexist while still permitting mutation of the inner T</code>. To support this, it never exposes a reference to the inner T</code> directly. Let us look at a minimal implementation: use std::cell::UnsafeCell; pub struct Cell<T> { value: UnsafeCell<T>, } // implied by UnsafeCell // impl<T> !Sync for Cell<T> {} impl<T> Cell<T> { pub fn new(value: T) -> Self { Cell { value: UnsafeCell::new(value), } } pub fn set(&self, value: T) { // SAFETY: we know no-one else is concurrently mutating self.value (because !Sync) // SAFETY: we know we're not invalidating any references, because we never give any out unsafe { *self.value.get() = value }; } pub fn get(&self) -> T where T: Copy, { // SAFETY: we know no-one else is modifying this value, since only this thread can mutate // (because !Sync), and it is executing this function instead. unsafe { *self.value.get() } } }</code></pre> Cell::get</code> returns a fresh copy of the inner value rather than a reference to it, ensuring that T</code> is never exposed externally. As a result, set can replace the inner value without any risk of dangling references. RefCell</h3> RefCell<T></code> takes a different approach: it shifts the responsibility of borrow checking from compile time to runtime. This is useful in situations where the compiler cannot statically prove the absence of aliased mutable references, but the developer can guarantee that at any given point at most one mutable reference exists — graph traversal being a common example. To achieve this, RefCell</code> internally tracks references through a runtime state counter. Below is a simplified implementation: use crate::cell::Cell; use std::cell::UnsafeCell; #[derive(Copy, Clone)] enum RefState { Unshared, Shared(usize), Exclusive, } pub struct RefCell<T> { value: UnsafeCell<T>, state: Cell<RefState>, } // implied by UnsafeCell // impl<T> !Sync for RefCell<T> {} impl<T> RefCell<T> { pub fn new(value: T) -> Self { Self { value: UnsafeCell::new(value), state: Cell::new(RefState::Unshared), } } pub fn borrow(&self) -> Option<Ref<'_, T>> { match self.state.get() { RefState::Unshared => { self.state.set(RefState::Shared(1)); Some(Ref { refcell: self }) } RefState::Shared(n) => { self.state.set(RefState::Shared(n + 1)); Some(Ref { refcell: self }) } RefState::Exclusive => None, } } pub fn borrow_mut(&self) -> Option<RefMut<'_, T>> { if let RefState::Unshared = self.state.get() { self.state.set(RefState::Exclusive); // SAFETY: no other references have been given out since state would be // Shared or Exclusive. Some(RefMut { refcell: self }) } else { None } } } pub struct Ref<'refcell, T> { refcell: &'refcell RefCell<T>, } impl<T> std::ops::Deref for Ref<'_, T> { type Target = T; fn deref(&self) -> &Self::Target { // SAFETY // a Ref is only created if no exclusive references have been given out. // once it is given out, state is set to Shared, so no exclusive references are given out. // so dereferencing into a shared reference is fine. unsafe { &*self.refcell.value.get() } } } impl<T> Drop for Ref<'_, T> { fn drop(&mut self) { match self.refcell.state.get() { RefState::Exclusive | RefState::Unshared => unreachable!(), RefState::Shared(1) => { self.refcell.state.set(RefState::Unshared); } RefState::Shared(n) => { self.refcell.state.set(RefState::Shared(n - 1)); } } } } pub struct RefMut<'refcell, T> { refcell: &'refcell RefCell<T>, } impl<T> std::ops::Deref for RefMut<'_, T> { type Target = T; fn deref(&self) -> &Self::Target { // SAFETY // see safety for DerefMut unsafe { &*self.refcell.value.get() } } } impl<T> std::ops::DerefMut for RefMut<'_, T> { fn deref_mut(&mut self) -> &mut Self::Target { // SAFETY // a RefMut is only created if no other references have been given out. // once it is given out, state is set to Exclusive, so no future references are given out. // so we have an exclusive lease on the inner value, so mutably dereferencing is fine. unsafe { &mut *self.refcell.value.get() } } } impl<T> Drop for RefMut<'_, T> { fn drop(&mut self) { match self.refcell.state.get() { RefState::Shared(_) | RefState::Unshared => unreachable!(), RefState::Exclusive => { self.refcell.state.set(RefState::Unshared); } } } }</code></pre> Two aspects are worth highlighting: the introduction of RefState</code> to track live references at runtime, and the fact that borrow and borrow_mut return the wrapper types Ref<T></code> and RefMut<T></code> — rather than bare &T</code> or &mut T</code> — so that RefState</code> can be updated correctly via their Drop</code> implementations when references go out of scope. Rc</h3> Rc</code> is a smart pointer that enables shared ownership of its inner data. Whereas ordinary values have a single owner with a compile-time-managed lifetime, data held inside an Rc</code> is heap-allocated and jointly owned, with a runtime reference count determining when the memory is freed. Below is a simplified implementation: use crate::cell::Cell; use std::marker::PhantomData; use std::ptr::NonNull; struct RcInner<T> { value: T, refcount: Cell<usize>, } pub struct Rc<T> { inner: NonNull<RcInner<T>>, _marker: PhantomData<RcInner<T>>, } impl<T> Rc<T> { pub fn new(v: T) -> Self { let inner = Box::new(RcInner { value: v, refcount: Cell::new(1), }); Rc { // SAFETY: Box does not give us a null pointer. inner: unsafe { NonNull::new_unchecked(Box::into_raw(inner)) }, _marker: PhantomData, } } } impl<T> std::ops::Deref for Rc<T> { type Target = T; fn deref(&self) -> &Self::Target { // SAFETY: self.inner is a Box that is only deallocated when the last Rc goes away. // we have an Rc, therefore the Box has not been deallocated, so deref is fine. &unsafe { self.inner.as_ref() }.value } } impl<T> Clone for Rc<T> { fn clone(&self) -> Self { let inner = unsafe { self.inner.as_ref() }; let c = inner.refcount.get(); inner.refcount.set(c + 1); Rc { inner: self.inner, _marker: PhantomData, } } } impl<T> Drop for Rc<T> { fn drop(&mut self) { let inner = unsafe { self.inner.as_ref() }; let c = inner.refcount.get(); if c == 1 { // SAFETY: we are the _only_ Rc left, and we are being dropped. // therefore, after us, there will be no Rc's, and no references to T. let _ = unsafe { Box::from_raw(self.inner.as_ptr()) }; } else { // there are other Rcs, so don't drop the Box! inner.refcount.set(c - 1); } } }</code></pre> Notable here is the use of Box</code> for heap allocation, a Cell-managed refcount shared across all Rc</code> instances, and a Drop</code> implementation that deallocates the inner data only when the reference count reaches zero. Multi-threaded Environments</h3> All of the containers and pointers covered so far are !Sync and intended for single-threaded use. In multi-threaded contexts, their thread-safe counterparts — Arc</code>, RwLock</code>, Mutex</code>, and others — are used instead. These deserve a dedicated discussion and will be covered separately in a future post. Summary</h3> Rust guarantees safety at compile time through the Aliasing NAND Mutability invariant.</li> Cell</code>, RefCell</code>, and Rc</code> each work around or reshape this rule by paying different costs: copying, runtime borrow checking, and runtime reference counting, respectively.</li> In multi-threaded environments, thread safety must also be considered, which is where Arc</code>, Mutex</code>, and RwLock</code> come in.</li> </ul> Reference</h3> This post is heavily based on Jon Gjentset's Crust of Rust — Smart Pointers and Interior Mutability</a> session. All code snippets appearing in this post are taken from that original session. If you are interested in this topic, watching the original video is highly recommended.

Reference</h3>
This post is heavily based on Jon Gjengset's Crust of Rust: Dispatch and Fat Pointers</a> session. If you're interested in this topic, watching the original video is highly recommended.</p>

Reference</h3>
As always, this post is heavily based on Jon Gjentset's Crust of Rust — Atomics and Memory Ordering</a> session. If you are interested in this topic, watching the original video is highly recommended.</p>

Reference</h3>
This post is heavily based on Jon Gjentset's Crust of Rust — Channels</a> session. Code snippets are also taken from the original session. If you are interested in this topic, watching the original video is highly recommended.</p>

Reference</h3>
This post is heavily based on Jon Gjentset's Crust of Rust — Send, Sync, and their implementors</a> session. Code snippets are taken from the official std documents. If you are interested in this topic, watching the original video is highly recommended.</p>

Reference</h3>
This post is heavily based on Jon Gjentset's Crust of Rust — Smart Pointers and Interior Mutability</a> session. All code snippets appearing in this post are taken from that original session. If you are interested in this topic, watching the original video is highly recommended.</p>

0xpluie

Rust's async/await: Why and How

Reference</h3>

Crust of Rust - async/await</a></li>
Why async Rust?</a></li> </ul>

Static vs Dynamic Dispatch in Rust

Your Code Doesn't Run the Way You Read It

Building a Rust Channel from Scratch

Making Sense of Send and Sync in Rust

Aliasing, Mutability, Containers and Pointers

0xpluie

Rust's async/await: Why and How

Reference</h3> Crust of Rust - async/await</a></li> Why async Rust?</a></li> </ul>

Static vs Dynamic Dispatch in Rust

Why do we need dispatch?</h3> Say we want to write a function that returns the length of a string. The most straightforward version looks like this:</p>

Reference</h3> This post is heavily based on Jon Gjengset's Crust of Rust: Dispatch and Fat Pointers</a> session. If you're interested in this topic, watching the original video is highly recommended.</p>

Your Code Doesn't Run the Way You Read It

Reference</h3> As always, this post is heavily based on Jon Gjentset's Crust of Rust — Atomics and Memory Ordering</a> session. If you are interested in this topic, watching the original video is highly recommended.</p>

Building a Rust Channel from Scratch

Sender and Receiver</h3> The basic interface is fairly straightforward. A channel requires a sender and a receiver, each equipped with send</code> and recv</code> methods respectively.</p>

Reference</h3> This post is heavily based on Jon Gjentset's Crust of Rust — Channels</a> session. Code snippets are also taken from the original session. If you are interested in this topic, watching the original video is highly recommended.</p>

Making Sense of Send and Sync in Rust

Reference</h3> This post is heavily based on Jon Gjentset's Crust of Rust — Send, Sync, and their implementors</a> session. Code snippets are taken from the official std documents. If you are interested in this topic, watching the original video is highly recommended.</p>

Aliasing, Mutability, Containers and Pointers

T, &mut T, &T</h3> In Rust, any arbitrary type T</code> can either be owned as T</code> itself, or used in two forms of aliases: &mut T</code> and &T</code>.</p>

Aliasing NAND Mutability</h3> Rust's borrow checker enforces a rule known as Aliasing NAND Mutability</em> to guarantee safety at compile time. That is:</p>

Reference</h3>

Crust of Rust - async/await</a></li>
Why async Rust?</a></li> </ul>

Reference</h3>
This post is heavily based on Jon Gjengset's Crust of Rust: Dispatch and Fat Pointers</a> session. If you're interested in this topic, watching the original video is highly recommended.</p>

Reference</h3>
As always, this post is heavily based on Jon Gjentset's Crust of Rust — Atomics and Memory Ordering</a> session. If you are interested in this topic, watching the original video is highly recommended.</p>

Reference</h3>
This post is heavily based on Jon Gjentset's Crust of Rust — Channels</a> session. Code snippets are also taken from the original session. If you are interested in this topic, watching the original video is highly recommended.</p>

Reference</h3>
This post is heavily based on Jon Gjentset's Crust of Rust — Send, Sync, and their implementors</a> session. Code snippets are taken from the official std documents. If you are interested in this topic, watching the original video is highly recommended.</p>