Cancelation -- use cases

[Joe Bowbeer]

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> 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?
>
>