[concurrency-interest] draft Carrier API
oleksandr.otenko at gmail.com
Tue Mar 10 07:48:24 EDT 2020
Thanks, that will probably work. Or some tryReceive version like poll with
timeout. Passing max_value is essentially blocking until closed or a value
arrives (or spurious wakeup-like condition).
On Tue, 10 Mar 2020, 11:30 Doug Lea via Concurrency-interest, <
concurrency-interest at cs.oswego.edu> wrote:
> On 3/9/20 3:29 PM, Alex Otenko wrote:
> > IllegalStateException is ok if receiver should've known there are no
> > more items to receive. This is a good idea in cases with definite length
> > of stream, and the length being known to the receiver before entering
> > receive(). This doesn't seem like a good idea for indefinite length
> > cases - like, loop to read all items until eof.
> This is the reason for:
> Stream<T> stream(); // destructive (consume-on-traverse)
> But it is also sensible to provide a simpler forEach analog:
> long consumeEach(Consumer<? super T> proc); // return count
> For those who need stateful loops, we could add "eventually" forms of
> tryReceive. With non-value-types, the preferable form that can co-exist
> with value-types is usually to return a resultIfAbsent (that is almost
> always chosen to be null), and for value types, Optional. To avoid
> annoying people, we should probably have both.
> T tryReceive(T resultIfAbsent); // resultIfAbsent if closed or empty
> Optional<T> tryReceive(); // Optional.empty if closed or empty
> T tryReceiveEventually(T resultIfAbsent); // resultIfAbsent if closed
> Optional<T> tryReceiveEventually(); // Optional.empty if closed
> Maybe there is a better method name.
> (See updates at http://gee.cs.oswego.edu/dl/wwwtmp/Carrier.java)
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest