Skip to content
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

Is there a way to make operations cancelable? #6

Open
getify opened this issue Apr 12, 2018 · 2 comments
Open

Is there a way to make operations cancelable? #6

getify opened this issue Apr 12, 2018 · 2 comments

Comments

@getify
Copy link
Owner

getify commented Apr 12, 2018

Explore some way to combine/bring in CAF (cancelable async functions) capabilities so that fasy's async iterations are optionally cancelable.

This might need to be a separate namespace where the API methods assume the cancelable token being passed in, or it may just be that existing methods could be polymorphic in some way.

Also to be explored: should fasy re-implement the cancelation, or should there be an adapter that can be optionally applied which delegates to CAF (which would need to be present separately) when needed.

@TheSench
Copy link

TheSench commented Jun 12, 2018

What is the expectation when an operation is cancelled?

  1. Would it return what it has retrieved so far?
  2. Would it return an empty result?
  3. Would it throw some kind of "Operation Aborted" exception?
  4. "And now for something completely different?"

Another consideration: what does cancelling a request mean to fasy? I assume if it were an asynchronous request to a server, you'd want to make sure that not only do you stop waiting for its promise to resolve, but that you actually abort the underlying request.

I'm guessing you'd want to ability to cancel a chain of requests, regardless of where in the flow you are (e.g. if you chained a concurrent map on getOrders for a list of users into another concurrent map on getOrderDetails on those orders, you'd probably want to use the same code to just "cancel it", regardless of which map it's on). If that's the case, perhaps add a method onto FA that returns a wrapped FA that has a cancel method and that adds its cancellation token to any requests made using its concurrent, serial, or transducers methods.

At my company, we were using some AngularJS services sitting atop $ajax to make batched OData calls and had to figure out how to cancel the operation if the user decided to change routes before the load finished. I ended up creating a function on our service that would wrap it up with a context (basically $scope and a pending request collection). Any $ajax requests made using that wrapper would be created with a cancellation promise. They would add that promise to the list of pending requests and remove it when they themselves resolved. If $scope got destroyed (or if the code using the wrapper explicitly asked to cancel requests), the cancellation promises would be resolved (and the pending $ajax calls would be aborted).

@getify
Copy link
Owner Author

getify commented Sep 23, 2018

Sorry for taking so long to respond. I think your observations make sense.

Since all fasy iterators return promises for their results, I think the most sensible thing is that canceled operations result in rejecting that promise.

Still trying to consider the ergonomics of specifying the CAF-style cancelation tokens.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants