- From: Kevin Gadd <kevin.gadd@gmail.com>
- Date: Tue, 30 Apr 2013 11:06:22 -0700
- To: "Sam L'ecuyer" <sam@cateches.is>
- Cc: Brendan Eich <brendan@mozilla.com>, es-discuss <es-discuss@mozilla.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>
- Message-ID: <CAPJwq3V7TPvQYw0WTwpyFMhUTg-7DNPQ9gmPg77zKHCHq6wsDw@mail.gmail.com>
Even if a consequence of cancellation is rejection (I'm not sure this is necessarily true), cancellation is different in that rejection comes from the source of the value, which is why it's on the resolver, while cancellation goes in the other direction - the recipient(s) of a value are telling the source that it is not needed, and the source is free to respond in any way it chooses. I should note that in my particular case, I did not map cancellation in my API to rejection; it's a separate state with separate callbacks and pipelines in part to avoid the problem of having confusion between whether a future was rejected or cancelled. I don't think it makes much sense for cancellation to reject a future since that would cause your existing rejection callback to get invoked with a cancellation error, when the odds are that *you* initiated the cancellation in the first place. I don't know what the right shape for a cancellation API is, but one should not assume that this problem is inherent to cancellation. I don't think it is. Cancellation may be hopelessly flawed as a feature in an ocap model where unprivileged consumers are sharing a single Future instance, though, because in that case I don't know how you would track the 'cancellation' state of a future across multiple unprivileged consumers, and it would probably expose a communication sidechannel just like weak references do. -kg On Tue, Apr 30, 2013 at 11:01 AM, Sam L'ecuyer <sam@cateches.is> wrote: > > Lucas Smith wrote: > >> IMO, cancelation is not appropriate for promises/futures. (sticking > >> with the name "promises", sorry for the distraction). > > > Agreed. > > Perhaps I'm missing something, but is cancel() conceptually different from > passing a Future's corresponding Resolver around so that the program can > invoke reject() at will? This seems like it's a new, "irretrievably > broken" way to do something you already can do. > > -sam > > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
Received on Tuesday, 30 April 2013 21:09:14 UTC