RE: Future cancellation

> -----Original Message-----
> From: Domenic Denicola [mailto:domenic@domenicdenicola.com]
> Sent: Tuesday, April 30, 2013 9:25 PM
> To: Jonas Sicking; Ron Buckton
> Cc: public-script-coord@w3.org; es-discuss
> Subject: RE: Future cancellation
> 
> From: es-discuss-bounces@mozilla.org [mailto:es-discuss-
> bounces@mozilla.org] On Behalf Of Jonas Sicking
> 
> > It isn't actually surprising that the same issues arise. ProgressFuture
> basically delivers progress about an "operation" rather than a "result".
> 
> I agree. I think both progress and cancellation (of underlying operations) are
> attractive nuisances. They seem like they fit in well with the model, and
> would be useful for certain use cases. But they are actually very different,
> and not tied to the underling promise semantics at all—which are of a first
> class value representing a promised "result," as you put it, not representing
> an ongoing "operation."
> 
> I lean toward not specifying or including them at all. Although you can try to
> stuff them naively into the promise semantics, you end up needing to
> complicate the conceptual model in order to make them behave as you wish.
> As you point out, this is clearly visible with the various combinators. But it's
> also visible in basic semantic questions that arise: e.g. downward progress
> propagation/transformation, or the role of throwing inside a progress
> handler, or upward cancellation progagation/reaction, or downward
> cancellation forking, or the role of rejections in cancellation. You soon realize
> that you're trying to smush in semantics where they don't belong.
> 
> In other words, separate abstractions for cancellation or progress, unrelated
> to promises, seem best.

This is roughly the case with .NET/C# cancellation. In .NET you use an external object to represent cancellation. If a function returns a Future (or "Task" in .NET), it's the function author's decision as to whether they want to accept a cancellation token. This allows the author control over whether they want to support cancellation. It's up to the caller to choose to construct a cancellation token and feed it to the function call. This allows for separation of responsibilities between the Future (which is only responsible for delivering asynchronous completion) and Cancellation (which can provide control over the operation). In .NET though, Tasks do participate in cancellation. They have a unique internal state that represents a cancelled task and a level of control over how to handle chained continuations (via the TaskContinuationOptions enum).

The same can be said for progress notifications in .NET Tasks, as they require a synchronization context to post progress notifications back to the caller who may be in a different thread.  This does illustrate your point though, regarding how Futures, cancellation, and progress are related but distinct.

Ron

Received on Wednesday, 1 May 2013 04:37:26 UTC