`select` statement for Java

[Alex Otenko]

So the actual equivalent using BlockingQueues would be:

Modify offer and poll non-blocking methods:

Either<T,CompletionStage<BlockingQueue<T>>> poll()

So that instead of value vs null you get a value or CompletionStage that is
completed when the queue is no longer empty. (Similar for offer - either
None, or a CompletionStage that is completed when the queue is no longer
full)

It's easy to see how such a primitive implements both blocking and
non-blocking behaviour: if you want to wait, you attach to the
CompletionStage; if you don't, you are non-blocking.

Now, given a list of such queues,

0. Construct a CompletableFuture
1. Shuffle
2. Fold that either finds a queue that returns a value and completes the
future with it, or constructs a chain combined with runAfterEither

3. runAfterEither runnable goes to step 1 (can bias towards the queue that
fired the non-empty first).


Alex

On Tue, 4 Feb 2020, 08:54 Alex Otenko, <oleksandr.otenko at gmail.com> wrote:

> It's not the same as blocking on N queues. That consumes N elements.
>
> Select consumes one element from some queue. It's like blocking on N
> queues, then push back N-1 elements before anyone else gets anything from
> those queues.
>
> Alex
>
> On Tue, 4 Feb 2020, 08:42 Dávid Karnok, <akarnokd at gmail.com> wrote:
>
>> What do you mean "multiple streams of events"? Merging them, zipping them,
>> combining them?
>>
>> > blocking on multiple `BlockingQueue`
>>
>> My impression about Loom is that most operators, especially multi-valued
>> streams, are DIY. So blocking on multiple queues means you block on each
>> in
>> its own virtual thread, then enqueue the object on another blocking queue
>> which you block for on the end consumer virtual thread. The complication
>> is, as with Flow.Publishers, when the number of input queues is dynamic,
>> how to propagate errors and indicate termination.
>>
>>
>> Doug Lea <dl at cs.oswego.edu> ezt írta (időpont: 2020. febr. 4., K, 1:33):
>>
>> > On 2/3/20 1:38 PM, Ryan Schmitt wrote:
>> > > Are there any current or planned constructs in Java that allow
>> blocking
>> > on
>> > > multiple streams of events simultaneously, similar to the `select`
>> > > statement in Go? I realize that technically speaking this is probably
>> > > orthogonal to Loom, but it seems like an important capability in
>> order to
>> > > get the most out of the blocking, imperative thread abstraction that
>> Loom
>> > > is fundamentally about.
>> > >
>> >
>> > Yes. We've been contemplating adding to java.util.concurrent a
>> > Loom-friendly channel-like component with select-like capabilities. I
>> > hope to write more about this in the coming months when it gets concrete
>> > enough to ask for feedback. For now: the most likely name is "Carrier",
>> > to distinguish from other channels and queues in Java.
>> >
>> > As others have noted, there's not likely to be special syntax, but the
>> > new pattern-match constructs should serve well. As in:
>> > switch(selector.receive()) { case Request r -> service(r); ... }
>> >
>> > -Doug
>> >
>> >
>> >
>> >
>>
>> --
>> Best regards,
>> David Karnok
>>
>