]> git.lizzy.rs Git - rust.git/commit
Rollup merge of #80269 - pickfire:patch-4, r=joshtriplett
authorYuki Okushi <jtitor@2k36.org>
Tue, 15 Jun 2021 08:39:58 +0000 (17:39 +0900)
committerGitHub <noreply@github.com>
Tue, 15 Jun 2021 08:39:58 +0000 (17:39 +0900)
commit2d2f1a5e88d6749edc3a51b4d68101e972d2ec25
tree4ce62f9f562a1f6e9edbc729f039d88b19e82ee7
parent9089771daf6b1f1824446cca3306d7c18084eae0
parent0f3c7d18fb1213ad285173210820924b76b534a1
Rollup merge of #80269 - pickfire:patch-4, r=joshtriplett

Explain non-dropped sender recv in docs

Original senders that are still hanging around could cause
Receiver::recv to not block since this is a potential footgun
for beginners, clarify more on this in the docs for readers to
be aware about it.

Maybe it would be better to show an example of the pattern where `drop(tx)` is used when it is being cloned multiple times? Although I have seen it in quite a few articles but I am surprised that this part is not very clear with the current words without careful reading.

> If the corresponding Sender has disconnected, or it disconnects while this call is blocking, this call will wake up and return Err to indicate that no more messages can ever be received on this channel. However, since channels are buffered, messages sent before the disconnect will still be properly received.

Some words there may seemed similar if I carefully read and relate it but if I am new, I probably does not know "drop" makes it "disconnected". So I mention the words "drop" and "alive" to make it more relatable to lifetime.
library/std/src/sync/mpsc/mod.rs