Cancelation -- use cases

[Brian Goetz]

So does that mean you think that the a5 case is kind of worrying about 
something we shouldn't worry about?

On 12/28/2012 11:33 AM, Joe Bowbeer wrote:
> I think of cancellation as a terminal condition that indicates the
> results are not needed:
>
> The user pushes the cancel button: stop and return control to the user.
>
> What you are describing in your a5 case seems like a notification or
> interrupt that may need to be handled cooperatively in order to preserve
> the work that has been completed.
>
>
>
>
> On Fri, Dec 28, 2012 at 8:20 AM, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     I've been working through some alternatives for cancellation support
>     in infinite streams.  Looking to gather some use case background to
>     help evaluate the alternatives.
>
>     In the serial case, the "gate" approach works fine -- after some
>     criteria transpires, stop sending elements downstream.  The pipeline
>     flushes the elements it has, and completes early.
>
>     In the parallel unordered case, the gate approach similarly works
>     fine -- after the cancelation criteria occurs, no new splits are
>     created, and existing splits dispense no more elements.  The
>     computation similarly quiesces after elements currently being
>     processed are completed, possibly along with any up-tree merging to
>     combine results.
>
>     It is the parallel ordered case that is tricky.  Supposing we
>     partition a stream into
>        (a1,a2,a3), (a4,a5,a6)
>
>     And suppose further we happen to be processing a5 when the bell goes
>     off.  Do we want to wait for all a_i, i<5, to finish before letting
>     the computation quiesce?
>
>     My gut says: for the things we intend to cancel, most of them will
>     be order-insensitive anyway.  Things like:
>
>       - Find the best possible move after thinking for 5 seconds
>       - Find the first solution that is better than X
>       - Gather solutions until we have 100 of them
>
>     I believe the key use case for cancelation here will be when we are
>     chewing on potentially infinite streams of events (probably backed
>     by IO) where we want to chew until we're asked to shut down, and
>     want to get as much parallelism as we can cheaply.  Which suggests
>     to me the intersection between order-sensitive stream pipelines and
>     cancelable stream pipelines is going to be pretty small indeed.
>
>     Anyone want to add to this model of use cases for cancelation?
>
>