A new build and a new structured concurrency API
Remi Forax
forax at univ-mlv.fr
Tue Nov 16 08:34:44 UTC 2021
Hi Ron,
I like the idea of StructuredExecutor + Handler but i think that given that each Handler (a completion policy?) has it's own semantics,
the API should be twisted a bit.
When we have,
String result;
try (var executor = StructuredExecutor.open()) {
var handler = new ShutdownOnSuccess<String>();
executor.fork(() -> fetch(left), handler);
executor.fork(() -> fetch(right), handler);
executor.join();
result = handler.result(e -> new WebApplicationException(e));
}
I notice several points,
- i don't like too much the fact that the handler is independent on the executor (not constructed with an executor) because it means that a user can create a handler store it in a static final and try to use it after. The lifercycle of the Handler should be coupled with the lifecycle on the executor.
- depending on the Handler, the API we want is slightly different, by example for a ShutdownOnSuccess, it would be cool to also propagate the type of the exception but it does noyt make a lot of sense to do that in case of a ShutdownOnFailure.
- join() and result() should be one method, again this is more true with a ShutdownOnSuccess than with a ShutdownOnFailure.
So i think it's better to move the operations fork() and join() on the Handler so the API can be tweaked to be specific to the completion policy.
By examples, for ShutdownOnSucess
int value;
try(var executor = StructuredExecutor.open()) {
var shutdownOnSuccess = new ShutdownOnSuccess<Integer, IOException>(executor);
//shutdownOnSuccess.fork(() -> 3);
shutdownOnSuccess.fork(() -> { throw new IOException(); });
value = shutdownOnSuccess.race();
}
System.out.println(value);
If we change fork() to take a functional interface like this
public interface CallableWithException<V, X extends Exception> {
V call() throws X;
}
So the method race(), which is join() + Handler.result() can be declared to throw X.
for ShutdownOnFailure, we may keep the classical fork/join API given that we can access the values using the futures
try(var executor = StructuredExecutor.open()) {
var shutdownOnFailure = new ShutdownOnFailure(executor);
var future1 = shutdownOnFailure.fork(() -> 3);
var future2 = shutdownOnFailure.fork(() -> 4);
shutdownOnFailure.join();
value = future1.get() + future2.get();
}
System.out.println(value);
regards,
Rémi
----- Original Message -----
> From: "Ron Pressler" <ron.pressler at oracle.com>
> To: "loom-dev" <loom-dev at openjdk.java.net>
> Sent: Lundi 15 Novembre 2021 21:21:45
> Subject: A new build and a new structured concurrency API
> Hi.
>
> We have just published a new Early Access build of Project Loom over on
> https://jdk.java.net/loom/
>
> The build is based on jdk-18+22, and now requires the --enable-preview flag to
> use Loom features (when compiling, remember to also add `--release 18`).
>
> The main new feature in this build is a new API for structured concurrency,
> called StructuredExecutor. To learn more about its motivation, capabilities,
> and use, please read this JEP draft [1] and the Javadoc [2]. Pay special
> attention to the new methods added to Future, resultNow and exceptionNow
> [3], and how they complement StructuredExecutor. One of the most exciting
> capabilities of StructuredExecutor is the new structured thread-dump mentioned
> in the JEP draft.
>
> Another new feature is the ability to use virtual threads as Cleaner threads
> [4]. We have also published a draft JEP for virtual threads [5]. The JEPs, like
> the project, are still a work in progress.
>
> As always, we appreciate feedback on these features from those who try them.
> Please, download the new EA and tell us about your experience.
>
> -- Ron
>
> [1]: http://openjdk.java.net/jeps/8277129
> [2]:
> https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredExecutor.html
> [3]:
> https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/Future.html
> [4]:
> https://download.java.net/java/early_access/loom/docs/api/java.base/java/lang/ref/Cleaner.html
> [5]: http://openjdk.java.net/jeps/8277131
More information about the loom-dev
mailing list