JEP 480: Structured Concurrency (Third Preview) Feedback

[Winkelman, Kyle G]

Thanks for the response! I should have taken more time to check out the EA build before messaging you. It has everything I wanted and more! All the examples I was messing around with felt great with the latest API.

As for java.lang.Process example, I have reported JDK-8342296<https://bugs.openjdk.org/browse/JDK-8342296> (should be enhancement, not bug) to hopefully create a more reliable paradigm.
  try (var scope = new StructuredTaskScope.open();
      var process = new ProcessBuilder(command).start()) {
    ... // scope.fork to read/write from stdin, stdout, stderr
  }

This still requires `process` to be defined second so that it is closed first. When Process.close() is called it will destroy the child process and the OS will close associated filedescriptors so the VirtualThreads can unblock to read EOF.

Is there anything else I could be doing to help push the story of Process cancellation/interruption? i.e. can we have the Process to expose getInputChannel/getOutputChannel/getErrorChannel backed by FileChannel and make similar changes to FileChannel as SocketChannel so that interrupting a virtual thread blocked on a read/write will unpark the thread.


P.S. Alan, I enjoyed watching your talk on the Devoxx/Java Youtube channels. It’s what inspired me to reach out.

From: Alan Bateman <alan.bateman at oracle.com>
Date: Wednesday, October 16, 2024 at 9:06 AM
To: Winkelman, Kyle G <kyle.winkelman at optum.com>, loom-dev at openjdk.org <loom-dev at openjdk.org>
Subject: Re: JEP 480: Structured Concurrency (Third Preview) Feedback

Caution: External email. Do not open attachments or click on links if you do not recognize the sender.


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<https://urldefense.com/v3/__https:/download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html__;!!IqUcNYopQPk7!Lzgrd_5dQk7nSMKRjf_B6OgtuwLGbWr4L41z1szNvb7Y-HW5vx1sILpVp9-IDXiHwi2SjXODAWrTbXKFDb_dv3AjOw$>

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or intended recipient’s authorized agent, the reader is hereby
notified that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20241016/58b15352/attachment-0001.htm>