search

rmanoka / async-scoped

A scope for async_std and tokio to spawn non-static futures
117 stars 14 forks source link

Question about `spawn_cancellable` #8

Closed xiaoniu-578fa6bff964d005 closed 3 years ago

xiaoniu-578fa6bff964d005 commented 3 years ago

In this line, why the code is *guard instead of !*guard?

xiaoniu-578fa6bff964d005 commented 3 years ago

It seems that makes the future cancelled instantly.

xiaoniu-578fa6bff964d005 commented 3 years ago

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?

xiaoniu-578fa6bff964d005 commented 3 years ago

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)?

rmanoka commented 3 years ago

@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?

xiaoniu-578fa6bff964d005 commented 3 years ago

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.

rmanoka commented 3 years ago

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.