"Cancelable" streams

[Remi Forax]

On 12/08/2012 10:51 PM, Brian Goetz wrote:
>> The main issue is that your example uses side effect,
>>    () -> cancelFlag.set(true)
>> which goes against the model
>
> The model is not "side effects are illegal"; we support forEach() and 
> into() which are side-effectful.  The model is more "don't use 
> side-effects where they are not needed."

forEach() and into() are terminal, not

>
>>  > Here, you might want to process until some threshold has been reached
>>  > (find the first N results), until some external event has occured
>>  > (process for five minutes and take the best result; process until the
>> asked to shut down.)
>>
>> find the N results => use limit()
>
> Parallel limit has some serious limitations that make it pretty 
> unsuitable for this case.  While these may be fixable, the effort and 
> distortion involved is far, far greater than what is being suggested 
> here.  In fact, I'm on the fence about whether to keep limit at all in 
> its current state; I worry people will expect more of it than it can 
> deliver, and be unhappy.

I don't get it. You can check the limit the very same way you want to 
check shouldCancel.

>
>> fitting the whole word and the kitchen sink into the Stream API is not a
>> goal.
>
> No, but this is a pretty lightweight cancelation mechanism -- far more 
> lightweight than limit as currently implemented.  We've talked to 
> customers who are very interested in using this for processing 
> infinite event streams.  The only thing missing is "how do I make it 
> stop."
>

And why this has to be included in the jdk ?
It seems to be a great use case to see if there is enough entrypoints in 
the jdk to implement that semantics externally.

Rémi