Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix documentation in tokio::sync::watch #5261

Merged
merged 2 commits into from Dec 4, 2022
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
8 changes: 4 additions & 4 deletions tokio/src/sync/watch.rs
Expand Up @@ -9,10 +9,10 @@
//! # Usage
//!
//! [`channel`] returns a [`Sender`] / [`Receiver`] pair. These are the producer
//! and sender halves of the channel. The channel is created with an initial
//! and consumer halves of the channel. The channel is created with an initial
//! value. The **latest** value stored in the channel is accessed with
//! [`Receiver::borrow()`]. Awaiting [`Receiver::changed()`] waits for a new
//! value to sent by the [`Sender`] half.
//! value to be sent by the [`Sender`] half.
//!
//! # Examples
//!
Expand Down Expand Up @@ -90,9 +90,9 @@ pub struct Sender<T> {
/// Returns a reference to the inner value.
///
/// Outstanding borrows hold a read lock on the inner value. This means that
/// long lived borrows could cause the produce half to block. It is recommended
/// long lived borrows could cause the producer half to block. It is recommended
/// to keep the borrow as short lived as possible. Additionally, if you are
/// running in an environment that allows `!Send` futures, you must ensure that
/// running in an environment that disallows `!Send` futures, you must ensure that
/// the returned `Ref` type is never held alive across an `.await` point.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is correct as written.

Copy link
Contributor Author

@Veetaha Veetaha Dec 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But if the environment allows !Send futures, then there is no restriction for holding a reference to Ref across an .await point. This restriction applies only when !Send futures are disallowed (e.g. multi-thread runtime).

So I still think this is a valid correction

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Holding a Ref across an .await is always bad because it can lead to a deadlock, but if !Send futures are disallowed, then you can't do it by accident since the compiler will catch it.

Copy link
Contributor Author

@Veetaha Veetaha Dec 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aha, I see this may lead to a panic or a deadlock... That's the piece I was missing. Maybe I should extend this comment to make it more explicit about what the aftermath is? WDYT?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's fine. (It can only lead to a deadlock, not a panic.)

Copy link
Contributor Author

@Veetaha Veetaha Dec 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a small clarification about the deadlock, and added a dash to long-lived and short-lived words as per the grammar.

I've noticed that this paragraph, which warns about holding a ref across an .await point, is repeated in several places. Some of them slightly differed from the doc comment on the struct Ref. I've updated them all to the same wording for consistency ✔️

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Darksonn waiting for your review

///
/// The priority policy of the lock is dependent on the underlying lock
Expand Down