Prevent basic_scheduler from panicking if a task is aborted from another thread #3672
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Darksonn
reviewed
Apr 4, 2021
Comment on lines
+64
to
+71
| // 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.
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 <alice@ryhl.io>
|
@Darksonn great suggestions. Thanks for taking a look! |
|
Hm, |
|
Ah, I thought tests were outside of MSRV, but clippy is still on MSRV, so. |
carllerche
approved these changes
Apr 8, 2021
|
I pinged the original issue author to see if they could verify the fix, but looks good to me. Thanks all ❤️ |
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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::spawnnotifies 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!