From 35835dda69bfa12b063aaf254bf67f5aba7cd122 Mon Sep 17 00:00:00 2001 From: Dodothereal <129273127+Dodothereal@users.noreply.github.com> Date: Tue, 23 Jun 2026 19:23:49 +0200 Subject: [PATCH] docs(ch21-03): note channel can still drain buffered messages Fixes #4673: 'When that happens' on its own doesn't distinguish between the buffered-message-still-drainable state and the sender-disconnected + buffer-empty state of mpsc channels. After drop(sender), workers can still recv() messages already in the queue; only when the buffer empties do recv() calls start returning Err. Replaced the single 'When that happens' with two clarifying sentences so the explanation lines up with the observed output in the graceful-shutdown run. --- src/ch21-03-graceful-shutdown-and-cleanup.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/ch21-03-graceful-shutdown-and-cleanup.md b/src/ch21-03-graceful-shutdown-and-cleanup.md index cfce45283b..4a28f3f622 100644 --- a/src/ch21-03-graceful-shutdown-and-cleanup.md +++ b/src/ch21-03-graceful-shutdown-and-cleanup.md @@ -115,8 +115,10 @@ here we _do_ need to use an `Option` to be able to move `sender` out of Dropping `sender` closes the channel, which indicates no more messages will be -sent. When that happens, all the calls to `recv` that the `Worker` instances do -in the infinite loop will return an error. In Listing 21-24, we change the +sent. Note that any messages already buffered in the channel can still be +received after the sender is dropped. Once the channel is empty and the +sender has disconnected, all the calls to `recv` that the `Worker` instances +do in the infinite loop will return an error. In Listing 21-24, we change the `Worker` loop to gracefully exit the loop in that case, which means the threads will finish when the `ThreadPool` `drop` implementation calls `join` on them.