`select` statement for Java

John Rose john.r.rose at oracle.com
Tue Feb 4 00:26:20 UTC 2020


On Feb 3, 2020, at 3:32 PM, Ryan Schmitt <rschmitt at pobox.com> wrote:
> 
> I've lurked on these mailing lists for a long time, and I promise this is not one of those "why don't you just" questions. I make reference to Go's `select` statement only as a convenient analogy for the kind of "multi-block" functionality I'm thinking about.

Good clarification.  And you didn’t say “syntax” in your first note, you said
“construct”.  I’m glad see you didn’t mean “syntax” but rather something like
what I called “notation” in my reply.

> What is interesting to me about this problem is that I don't see a way to implement any kind of functionality like this, *except on top of asynchronous code*. I'm not aware of any primitives in Java that you could use to build multiplexed blocking operations, such as blocking on multiple `BlockingQueue` instances. I'm curious to hear what the experts think of this problem.

There are such primitives in Java, which apply to suitably
conditioned sets of blocking operations.  They don’t (at
present) cover all the blocking channel APIs, just a few.

Perhaps you haven't seen java.nio.channels.Selector or
CompletableFuture.html::anyOf, or else you don’t count
them as suitable foundations for blocking operations.
Either way, that is the sort of starting point we were at
before Loom.

I’ll let the Loom team respond further, after I point
out two more things:  The Loom team is refactoring
the internals of the JDK concurrency APIs to be fiber-friendly
which means scheduler-friendly, so you can expect
to see robust selection infrastructure along with Loom.
And, to close the loop on your original request, such
API points (which will be like the ones I mentioned
but surely better) will be the primitives on top of which
a switch-friendly wrapper API (with a future version of
switch) would create a notation competitive with Go’s
select statement.

— John


More information about the loom-dev mailing list