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).
More information about the es-discuss