Cancellation architectural observations

Tab Atkins Jr. jackalmage at gmail.com
Tue Mar 3 00:08:51 UTC 2015


On Mon, Mar 2, 2015 at 3:52 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> So I think I'm persuaded by the argument that as long as an API
> returns a Promise, there is no way that we can put a
> cancellation/result-ignoring/close() API on that Promise. It seems to
> simply break the Promise contract.
>
> Instead we'd need to return some object which allows us to track
> consumers. I.e. where if you call a .then-like function, you prevent
> anyone else from doing so. And if you want to enable others to consume
> the result, you have to first fork the result and then call the
> .then-like function on your fork.
>
> Unfortunately that .then-like function probably can't be called "then"
> given the elevated status that Promises has given that function name.

This was the approach I was angling for early in the FetchPromise
thread at <https://github.com/slightlyoff/ServiceWorker/issues/625#issuecomment-75302002>;
I originally proposed that .then() always return a vanilla Promise,
and a separate method (I proposed .pipe()) do a chain that maintained
the cancellability (triggering refcounting and such).

~TJ


More information about the es-discuss mailing list