Document guarantee: `sync_channel` `send()` ⇒ immediate `try_recv()` visibility.

[jhfrontz]

Location (URL)

Maybe https://doc.rust-lang.org/std/sync/mpsc/fn.sync_channel.html

Summary

Request: Make explicit in std::sync::mpsc::sync_channel docs that after Sender::send returns Ok(()), the message is enqueued such that an immediate Receiver::try_recv() on the same channel cannot return Empty.

Rationale: This is relied on for tests (where code calls send() and the test immediately calls try_recv() on the same channel to assert a message was produced). Implementation appears to already behave this way, but the guarantee isn’t stated. It's conceivable that in a different environment that an alternate implementation might be used that introduces the potential for messaging latency.

Ask: Treat this as a normative docs change.

(Reference: https://stackoverflow.com/questions/79753705/rust-mpscsync-channel-after-send-returns-can-try-recv-still-return-empty )

[jhfrontz]

@rustbot label +T-libs-api
This is intended as a normative docs request. Sorry if that's not the right label.

[lukaslueg]

It's probably important to point out that the SO-question this came from refers to "send() and try_recv() on the same thread". That is, can channel guarantee that if send() returns Ok(()), a try_recv() on the same thread will always return an item?