Skip to content

docs(ch21-03): clarify channel state after sender drop (#4673)#4781

Open
Dodothereal wants to merge 1 commit into
rust-lang:mainfrom
Dodothereal:fix/issue-4673-buffer-after-sender-disconnect
Open

docs(ch21-03): clarify channel state after sender drop (#4673)#4781
Dodothereal wants to merge 1 commit into
rust-lang:mainfrom
Dodothereal:fix/issue-4673-buffer-after-sender-disconnect

Conversation

@Dodothereal

Copy link
Copy Markdown

Fixes #4673

Summary

In ch21-03, 'When that happens' immediately presupposes that
dropping the sender forces recv() to error, but mpsc channels can
still drain messages already buffered after the sender is dropped.
The discrete observation in the issue is that sample
graceful-shutdown output shows a worker still receiving a job after
the 'Shutting down worker N' message — consistent with buffering.

Add two short sentences flagging the buffered state. No code or
listing changed.

Test plan

  • git diff: single file, 4 insertions, 2 deletions.
  • Listings untouched.

AI assistance

Prepared with help from an AI coding assistant; reviewed end-to-end.

Fixes rust-lang#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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Ch 21.3 - recv receives Ok(T) Buffered Messages after Sender has disconnected

1 participant