Cancelable streams

[David Holmes]

On 5/11/2012 2:30 PM, Joe Bowbeer wrote:
>  > Plus, the ability to query the gate to determine whether the pipeline
> finished because it was out of elements, or because the gate was
> manually closed.
>
> In my view, closing the gate doesn't "finish" the stream, it just stalls
> it.  Gates open and close.  They can be used to delay the start until
> the appointed time, regulate the passage of elements, pause, resume, etc.

Agreed. Further, just because the gate is now closed it doesn't mean 
that you didn't run out of data first - there is an inherent race here 
unless the gate returns a sentinel of some kind.

But to be honest while the pipeline abstraction is nice and I can see a 
"gate" within a pipeline as being open or closed, I don't see how you 
can insert a user-defined gating function into an arbitrary pipeline. 
The gate itself is not just a predicate but a stateful object 
potentially with its own API.

Further, I would only expect the code that creates the pipeline, and the 
gate, to be able to query the gate. I don't see how the gate would be 
visible further down the pipeline.

David

>
>
> On Sun, Nov 4, 2012 at 8:13 PM, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
>      > In essence I think you want to insert a "gate" operation into the
>     pipeline - while the gate is open elements can be read from the
>     stream, but when it is closed they can not. The question then
>     becomes how you control the gate, either from within the pipeline
>     (predicate based) or externally (time-trigerred callback).
>
>     Yes, that is exactly what I am suggesting.  Plus, the ability to
>     query the gate to determine whether the pipeline finished because it
>     was out of elements, or because the gate was manually closed.
>
>