Future cancellation

Tab Atkins Jr. jackalmage at gmail.com
Wed May 1 11:10:45 PDT 2013


On Wed, May 1, 2013 at 9:38 AM, Jonas Sicking <jonas at sicking.cc> wrote:
> On May 1, 2013 8:21 AM, "Tab Atkins Jr." <jackalmage at gmail.com> wrote:
>>
>> On Wed, May 1, 2013 at 12:16 AM, Jonas Sicking <jonas at sicking.cc> wrote:
>> > However with this approach you get an API which automatically simply
>> > works as an API returning a Future in case you don't need to abort the
>> > operation or display its progress:
>> >
>> > handleResult(doSomeOperation());
>> > or
>> > return doSomeOperation();
>> > or
>> > doSomeOperation().then(val => displayResult(val));
>> >
>> > I.e. if you don't care about the operation part, the API simply works
>> > as any other API which returns a promise. This seems like a very nice
>> > thing. The only "cost" of this API is that it doesn't compose when you
>> > compose the future, but neither does the dispose object in the tuple
>> > approach.
>>
>> The other cost is an inherent capability leak - *unless* you purposely
>> strip it of its cancelability, passing it around to anything else
>> gives the "anything else" the ability to cancel your promise as well.
>> The tuple approach doesn't have this issue - the promise and the
>> canceler/resolver are inherently separated, and you have to purposely
>> hand the canceler/resolver off to other code for it to have any
>> powers.
>
> This is a problem that the current XHR API is suffering from too. Has that
> been a problem in reality?
>
> With XHR you can even affect the values that other consumers are receiving
> by setting .response type. Again, does anyone have examples of when this has
> been a problem?
>
> I feel like attempting to solve this problem will mean that we need to split
> a lot of interfaces into lists of objects, each representing a capability.
> This seems like it will very quickly lead to an unmanageable mess.

I don't think this is a valid slippery-slope argument.  If it were
true, it would show itself more strongly, as us, for example,
splitting up the resolver into two or three different objects for each
of the operations, and maybe the promise into two objects as well for
each of the channels.

In practice, you can split things into capabilities that are
reasonable to group together.  However, a cancellable promise blurs
the line.  Maybe that's not important?  I dunno.

> Wrapping a CancelableFuture in a normal Future seems like an acceptable
> solution which only adds complexity in the much more rare case that someone
> cares about capabilities.

If we knew that chaining a CancelableFuture always returned a normal
Future, then this might be okay - just do
"getCancellableFuture(foo).then()" to get a normal future out.

~TJ


More information about the es-discuss mailing list