Closed xiaoniu-578fa6bff964d005 closed 3 years ago
It seems that makes the future cancelled instantly.
Another question: What is the difference between CancellableFuture
and futures::future::Abortable
?
If I only spawn one single future, then is futures::future::Abortable
a more favorable choice?
Another question: If cancellation is implemented correctly (e.g. all spawned futures are cancelled when the scope is dropped), then how unsafe fn scope
is?
Is it possible that we have a safe interface (at least for use case when we only spawn one single future)?
@xiaoniu-578fa6bff964d005
In this line, why the code is
*guard
instead of!*guard
?
I believe you're right: the if condition should indeed be inverted. Should add a test for this functionality, and fix this.
Another question: What is the difference between CancellableFuture and futures::future::Abortable?
A quick glance does suggest that we could swap it out for Abortable
. I suppose the Scope
structure will hold the AbortRegistration
and use that in spawn_cancellable
. Would need a more thorough look at the semantics of Abortable
to ensure the safety requirements are withheld: nothing within the inner future should be accessed once aborted as it may contain references that have expired.
Another question: If cancellation is implemented correctly (e.g. all spawned futures are cancelled when the scope is dropped), then how unsafe fn scope is?
The safety issue with Scope
creation is that there is no guarantee that the Scope
is not forgotten via mem::forget
instead of being dropped. Thus, the cancellation / abort mechanism might not kick in before the references used within the spawned futures expire. This is why the only safe interface is to spawn and block on the scope.
Thanks for looking at it and your findings. Would you be able to contribute a PR to fix the guard logic, and may be also to verify and switch over to Abortable
?
Thank you for the detailed answer. I have found a workaround for my use case, therefore currently I have no strong motivation for a PR to this project. However, I believe this crate is useful under certain circumstances and I might have a revisit in the future.
Thanks for pointing this out. As we discussed, I've moved to using futures::Abortable
which also simplifies the code base. FIxed in 0.7.0.
In this line, why the code is
*guard
instead of!*guard
?