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

sync: fix Notify to clone the waker before locking its waiter list #4129

Merged
merged 1 commit into from
Sep 23, 2021

Conversation

seanmonstar
Copy link
Member

Since a waker can trigger arbitrary code, such as with a custom waker,
and even more so now that it can emit a tracing event that could do
respond, we must be careful about the internal state when that code is
triggered. The clone method of a waker is one of those instances.

This changes the internals of Notify so that the waker is cloned
before locking the waiter list. While this does mean that in some
contended cases, we'll have made an optimistic clone, it makes Notify
more robust and correct.

Note that the included test case is built from an instance that did
happen naturally in another project, see
tokio-rs/console#133.

@hawkw
Copy link
Member

hawkw commented Sep 22, 2021

rustfmt ci seems a bit upset?

Copy link
Member

@hawkw hawkw left a comment

Choose a reason for hiding this comment

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

this looks good to me!

it appears that rustfmt needs to be run on the test.

Since a waker can trigger arbitrary code, such as with a custom waker,
and even more so now that it can emit a tracing event that could do
respond, we must be careful about the internal state when that code is
triggered. The clone method of a waker is one of those instances.

This changes the internals of `Notify` so that the waker is cloned
*before* locking the waiter list. While this does mean that in some
contended cases, we'll have made an optimistic clone, it makes `Notify`
more robust and correct.

Note that the included test case is built from an instance that did
happen naturally in another project, see
tokio-rs/console#133.
@seanmonstar seanmonstar force-pushed the sean/notify-waker-clone-before-lock branch from a97d55b to d91a448 Compare September 22, 2021 22:03
@seanmonstar
Copy link
Member Author

Oh yea, cargo fmt does nothing in Tokio directories, I forgot.

@Darksonn Darksonn added A-tokio Area: The main tokio crate M-sync Module: tokio/sync labels Sep 23, 2021
@Darksonn Darksonn merged commit ea19606 into master Sep 23, 2021
@Darksonn Darksonn deleted the sean/notify-waker-clone-before-lock branch September 23, 2021 06:33
suikammd pushed a commit to suikammd/tokio that referenced this pull request Oct 7, 2021
…okio-rs#4129)

Since a waker can trigger arbitrary code, such as with a custom waker,
and even more so now that it can emit a tracing event that could do
respond, we must be careful about the internal state when that code is
triggered. The clone method of a waker is one of those instances.

This changes the internals of `Notify` so that the waker is cloned
*before* locking the waiter list. While this does mean that in some
contended cases, we'll have made an optimistic clone, it makes `Notify`
more robust and correct.

Note that the included test case is built from an instance that did
happen naturally in another project, see
tokio-rs/console#133.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-tokio Area: The main tokio crate M-sync Module: tokio/sync
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants