-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Prevent basic_scheduler from panicking if a task is aborted from another thread #3672
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see any problems in the implementation, but it would be nice with another set of eyes.
// This runs in a separate thread so it doesn't have immediate | ||
// thread-local access to the executor. It does however transition | ||
// the underlying task to be completed, which will cause it to be | ||
// dropped (in this thread no less). | ||
assert!(!drop_flag2.load(Ordering::SeqCst)); | ||
j.abort(); | ||
// TODO: is this guaranteed at this point? | ||
// assert!(drop_flag2.load(Ordering::SeqCst)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well if the task's destructor runs in this thread, it would be, but it's unclear to me that the destructor would necessarily run here.
Co-authored-by: Alice Ryhl <[email protected]>
@Darksonn great suggestions. Thanks for taking a look! |
Hm, |
Ah, I thought tests were outside of MSRV, but clippy is still on MSRV, so. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, it looks a lot like how the multi-threaded scheduler handles this.
I pinged the original issue author to see if they could verify the fix, but looks good to me. Thanks all ❤️ |
Motivation
This purports to fix the bug reported in #3662
Solution
The first commit simply ignores that the context is missing. What happens then (to the best of my understanding) is that the task header stays linked in the scheduler until the the scheduler is dropped. Any future polls of the task will simply never reach the scheduler, but be stopped by the harness and report the cancellation since it's already aware of the task state.
That leads us to the second commit, where I try to add a mechanism for remotely notifying the scheduler to remove the linked task. This is similar to how
tokio::spawn
notifies the thread about new tasks if run from a different thread (as it would if used from inside atokio::spawn_blocking
). This should result in the task eventually being cleaned under one of the following circumstances:Poll::Pending
.The sketchy part here is that the shared task header is being sent from the thread releasing the task. Which should be fine in principle but it's a bit messy.
This is the first time I'm fiddling w/ basic_scheduler. So please pay close attention to if I've misunderstood something!