3 ms·

You can also use cancellation tokens with promises. Pretty easy to do and doesn't require a library.

by inglor 9y ago

Rapzid 9y ago
There is a cancellation library kicking around npm that reasonably mimics C#'s. There must have been man-years of discussion on the Bluebird project around cancellation, but for me it all comes back to tokens as every promise baked-in solution feels a bit off. Golang effectively has them as well via the context package. *As you say it is pretty easy to do, but it's nice to standardize on an implementation
- inglor 9y ago
  Yes, we've been reading all the golang discussion very carefully. It's nice to see them go through the same mental process we went through - and my hopes are that if we don't interfere they'll come up with a better idea we can just copy. We've had 4 cancellation proposals rejected so far (cancellation as rejection, third state, cancellable-promise and cancel-tokens). They work in bluebird pretty well - but people have concerns. Personally I use our cancellation if I already have bluebird, and tokens if I don't.
Mitranim 9y ago
Not familiar with cancelation tokens. Can you describe the approach?
- mikewhy 9y ago
  You pass them to an asynchronous function and said function can do something like `token.throwIfCancelled()` if you've called `token.cancel()` elsewhere.
  - Mitranim 9y ago
    Doesn't sound as ergonomic as just returning a cancelation function in a future initialiser. Not seeing any other advantages, either. Am I missing some?
    - inglor 9y ago
      Your idea was described by kriskowal in 2013 (see https://github.com/kriskowal/gtor https://github.com/kriskowal/gtor ) - in the promises community we call them "Tasks". Basically, you can make it work pretty easily with promises and multicast (by reference counting). The reason they're not added to promises is because some people feel they break a guarantee a promise makes. Not only is it possible - it works well. Domenic is worn out from having to put up with all the involved shit (if you're reading this, sorry :D). He put a lot of work but I think he's tired of fighting for this rather than push other areas where he meets less resistance in the DOM. I just wanted to point out that while cancellation is a whole world of complexity and is very interesting - it's not avoided in the language because we're stuck on the technical side.
      - Mitranim 9y ago
        Interesting! Nice that the approach is known, and others are being discussed. I should check GTOR again. Multicast cancelation based on refcounting doesn't look right to me. I explicitly avoided this in Posterus, sticking with exclusive ownership, what GTOR calls unicast (thanks for linking). The reason is that subscribers may come and go over time. I've seen, and written, code that caches a promise and reuses it many times. It may start with one consumer, lose it, be canceled, then another consumer comes and gets rejected. This just feels like a big footgun. In Posterus, multicast is explicit and opt-in (`.weak()` futures). If we eventually standardise a solution, I'd like something with as few interfaces as possible. In a dynamic language, you don't have the luxury of creating a future that initialises into a task, returning a cancelation token. Too many types without static checking is just a footgun. This is part of why Posterus only has futures, why cancelation is provided in the future constructor and tied to the future itself, and why they're eager rather than lazy. Deviating from these constraints would introduce new types, increasing the footgun potential.
    - inglor 9y ago
      Also, I hope I don't sound cocky or rude in my other reply. I have mad respect to people who actually go and build stuff instead of complaining. It's a great way to learn and contribute - and who knows maybe we'll all be using your library in 5 years :D

You can also use cancellation tokens with promises. Pretty easy to do and doesn't require a library.

by inglor 9y ago

You can also use cancellation tokens with promises. Pretty easy to do and doesn't require a library.

There is a cancellation library kicking around npm that reasonably mimics C#'s. There must have been man-years of discussion on the Bluebird project around cancellation, but for me it all comes back to tokens as every promise baked-in solution feels a bit off. Golang effectively has them as well via the context package. *As you say it is pretty easy to do, but it's nice to standardize on an implementation

inglor 9y ago
Yes, we've been reading all the golang discussion very carefully. It's nice to see them go through the same mental process we went through - and my hopes are that if we don't interfere they'll come up with a better idea we can just copy. We've had 4 cancellation proposals rejected so far (cancellation as rejection, third state, cancellable-promise and cancel-tokens). They work in bluebird pretty well - but people have concerns. Personally I use our cancellation if I already have bluebird, and tokens if I don't.

Mitranim 9y ago

Not familiar with cancelation tokens. Can you describe the approach?

mikewhy 9y ago
You pass them to an asynchronous function and said function can do something like `token.throwIfCancelled()` if you've called `token.cancel()` elsewhere.
- Mitranim 9y ago
  Doesn't sound as ergonomic as just returning a cancelation function in a future initialiser. Not seeing any other advantages, either. Am I missing some?
  - inglor 9y ago
    Your idea was described by kriskowal in 2013 (see https://github.com/kriskowal/gtor https://github.com/kriskowal/gtor ) - in the promises community we call them "Tasks". Basically, you can make it work pretty easily with promises and multicast (by reference counting). The reason they're not added to promises is because some people feel they break a guarantee a promise makes. Not only is it possible - it works well. Domenic is worn out from having to put up with all the involved shit (if you're reading this, sorry :D). He put a lot of work but I think he's tired of fighting for this rather than push other areas where he meets less resistance in the DOM. I just wanted to point out that while cancellation is a whole world of complexity and is very interesting - it's not avoided in the language because we're stuck on the technical side.
    - Mitranim 9y ago
      Interesting! Nice that the approach is known, and others are being discussed. I should check GTOR again. Multicast cancelation based on refcounting doesn't look right to me. I explicitly avoided this in Posterus, sticking with exclusive ownership, what GTOR calls unicast (thanks for linking). The reason is that subscribers may come and go over time. I've seen, and written, code that caches a promise and reuses it many times. It may start with one consumer, lose it, be canceled, then another consumer comes and gets rejected. This just feels like a big footgun. In Posterus, multicast is explicit and opt-in (`.weak()` futures). If we eventually standardise a solution, I'd like something with as few interfaces as possible. In a dynamic language, you don't have the luxury of creating a future that initialises into a task, returning a cancelation token. Too many types without static checking is just a footgun. This is part of why Posterus only has futures, why cancelation is provided in the future constructor and tied to the future itself, and why they're eager rather than lazy. Deviating from these constraints would introduce new types, increasing the footgun potential.
  - inglor 9y ago
    Also, I hope I don't sound cocky or rude in my other reply. I have mad respect to people who actually go and build stuff instead of complaining. It's a great way to learn and contribute - and who knows maybe we'll all be using your library in 5 years :D