Cancelable streams (original) (raw)

Joe Bowbeer joe.bowbeer at gmail.com
Sun Nov 4 07:00:41 PST 2012

Thanks. I can understand the use case.

Monte Carlo techniques, even monte carlo image production, where the user is holding their finger on a can of spray paint for a certain period of time. And in a computer simulation (or a paint program), the user may actually control the simulation by holding their finger on a (virtual) button, or by flipping a switch.

I do think it's interesting to think how one could insert such a "regulator" into a pipeline of function applications, rather than controlling everything at the generator.

If the Stream (and ParallelStream) elements are obtained entirely by "pull" then it should be possible to create a stage where the elements are produced (or not) according to a timer or external signal, which seems like a generalization of your problem: an element is produced every time a signal is received.

Do the interfaces permit this?

On Sun, Nov 4, 2012 at 5:01 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> I'm familiar with infinite streams (I was a tech. reviewer for the original Wizard Book) but I'm not familiar with your approach to cancellation. Is there any precedent for it?

This is a use case that shows up in real-time analytics. There's a stream of data, and you want to chew on it for as long as you have cycles, but want to shut down gracefully when asked to. > To handle cancellation, I would signal the generator to stop returning elements, or to generate a (null) marker to signal end of stream. > > In other words, cancellation should be handled at the generator, not by Streams in general. And this discussion is basically over the use of the word "should" in the above sentence. There are lots of places it could be handled, including just telling the user to cut the the power to the box when they're done.

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