Question about `spawn_cancellable` about async-scoped HOT 6 CLOSED

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.

from async-scoped.

It seems that makes the future cancelled instantly.

from async-scoped.

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?

from async-scoped.

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

from async-scoped.

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

from async-scoped.

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.

from async-scoped.