JEP 480: Structured Concurrency (Third Preview) Feedback

[Alan Bateman]

Thanks for taking the time to write a mail on your experiences.

On 15/10/2024 18:13, Winkelman, Kyle G wrote:
>
> Things that felt strange or annoying:
>
>   * When subclassing StructuredTaskScope I always have to @Override
>     `join` and `joinUntil` to return my subclass type to provide a
>     fluent api.
>

When doing a custom policy, and the subclass defines methods to make 
available the outcome, then you do need to override the join method with 
a covariant return type to make it possible for use sites to make use of 
method invocation chaining. The override will likely just do 
super.join() so shouldn't be too much of a burden, just a bit annoying.

There is an update to the API [1] in the EA builds and draft JEP that 
moves the policy to a side object with a type parameter on STS for the 
return from join. That takes the burden of subclassing off the table.



>   * When subclassing StructuredTaskScope @Override `handleComplete` I
>     find myself wanting to write a switch expression on
>     Subtask#state(), but if I do, I always need to have a case for
>     UNAVAILABLE and throw IllegalStateException.
>   * Using StructuredTaskScope (no subclassing) feels weird because you
>     must decide to use either the `<>` diamond operator to allow any
>     types or define a type T for restricting subtasks (makes you
>     wonder if you are using it correctly). Whereas, both
>     ShutdownOnFailure and ShutdownOnSuccess just feel right to use.
>
The code example you included had subtasks that yield results of 
different types. There are cases where the tasks will all return 
something of the same type. Using STS directly is the equivalent of "no 
policy" so closer to the ES.invokeAll in that regard. The default in the 
updated API is changed to work like ShutdownOnFailure in the existing 
API because this is likely the 90% case.


>  *
>
>
>
>   * In IntelliJ the Javadoc of StructuredTaskScope doesn’t seem to
>     properly format and makes it very difficult to read (probably an
>     issue with IntelliJ).
>
I don't know what this except to note that the API docs have several 
code snippets, maybe the IDE version you are using can't handle this.


>
>   * Blocking IO is not interruptible and this can cause confusion when
>     the scope won’t close in a timely manner even though something may
>     have already thrown an exception (probably falls under the
>     Non-Goal of thread cancellation mechanism). e.g. 2 calls to fork
>     one reading a short file and the other reading an long file, short
>     one fails, if I don’t do something to close the long file stream I
>     will read the whole thing (making ShutdownOnFailure not really
>     live up to its name).
>

Our expectation is that STS will be mostly used for fan out to network 
services. The blocking Socket methods were re-specified in JDK 19 so 
that interrupt closes the Socket, similar to interruptible channels, 
when used in the virtual threads. SocketChannel is an interruptible 
channel so okay there, even when configured blocking.

Your example launches sub-Processes which doesn't have a good story for 
cancellation/interrupt. I hope in time that it will get attention.

-Alan


[1] 
https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20241016/90a58db5/attachment.htm>