Cancelable streams

[Joe Bowbeer]

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