You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The implementation of abort in #87 as detaching the task does not seem right, because detached tasks may still continue to run. Consider the following test, which should not fail but currently does.
#[test]fnjoin_handle_abort_bug(){check_dfs(
|| {let(sender, receiver) = futures::channel::oneshot::channel();let t = future::spawn({asyncmove{
receiver.await.unwrap();panic!("should not get here");}});
t.abort();
sender.send(()).unwrap();
shuttle::thread::yield_now();},None,);}
(The yield_now is needed because otherwise the main task would immediately finish, in which case also the execution finishes because there are no attached tasks left.)
We need a way to actually cancel a task, which drops its continuation and returns a JoinError indicating cancellation.
The text was updated successfully, but these errors were encountered:
abort is funny because it's best-effort and so non-deterministic when the task should stop. The current implementation doesn't do that. Maybe just always canceling the task immediately is a better default, but it can miss executions, in the same way our wait_timeout implementations can miss executions.
The implementation of
abort
in #87 as detaching the task does not seem right, because detached tasks may still continue to run. Consider the following test, which should not fail but currently does.(The
yield_now
is needed because otherwise the main task would immediately finish, in which case also the execution finishes because there are no attached tasks left.)We need a way to actually cancel a task, which drops its continuation and returns a
JoinError
indicating cancellation.The text was updated successfully, but these errors were encountered: