-
Notifications
You must be signed in to change notification settings - Fork 576
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Task Cancellation #18
Comments
I've been wondering the same thing. Thanks for asking. |
It's generally bad design to keep track of the So a better model is to create a "cancellation token" at the top level, and pass that to each async function that you want to be part of the same "cancelable operation". Then, in your continuation blocks, you can check whether the cancellation token has been cancelled and bail out early by returning a We are likely to add some concept like this to Bolts at some point in the future. In the meantime, you can use an
|
Cool, thanks for advice! I guess It might be a good idea to propose the cancellation token approach in the README? |
Yeah, I think so. Feel free to open a pull request. ;-) Or we will add it later. |
Already on it. |
Based on [comment](BoltsFramework#18 (comment)) in BoltsFramework#18
Based on [comment](BoltsFramework#18 (comment)) in BoltsFramework#18
I was wondering, what is the intended approach to task cancellation?
BFTask
only exposes methods for task consumption and continuation, while the cancellation is implemented throughBFTaskCompletionSource
(which actually just calls internal cancellation methods ofBFTask
).There is no way to cancel a
BFTask
without having a reference to its completion source.Does this mean that a task producer should keep a reference to all its long-running cancellable task completion sources and expose an interface for identifying and cancelling a specific task?
The text was updated successfully, but these errors were encountered: