Cancelation -- use cases (original) (raw)

Joe Bowbeer joe.bowbeer at gmail.com
Fri Dec 28 08:33:57 PST 2012

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 ai, 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? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20121228/86b19b8b/attachment.html

More information about the lambda-libs-spec-experts mailing list