Prevent basic_scheduler from panicking if a task is aborted from another thread #3672
Conversation
Darksonn
left a comment
Darksonn
left a comment
There was a problem hiding this comment.
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.
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. |
carllerche
left a comment
carllerche
left a comment
There was a problem hiding this comment.
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 ❤️ |
3 participants
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!