kevin.gadd at gmail.com
Tue Apr 30 11:06:22 PDT 2013
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
On Tue, Apr 30, 2013 at 11:01 AM, Sam L'ecuyer <sam at 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.
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss