JEP 425 (Virtual Threads) - Cancellation

Attila Kelemen attila.kelemen85 at gmail.com
Mon May 2 09:15:52 UTC 2022


Alan Bateman <Alan.Bateman at oracle.com> ezt írta (időpont: 2022. máj.
2., H, 9:42):
>
> Search for the sentence "To allow for interruption and cancellation, the
> blocking I/O methods ..." in the Networking section of the JEP as it
> deals with this topic.

That part seems to be only about sockets, while I would like to see the other
most common I/O operations to address the problem. Sure, as David mentioned
in a previous email, it is not a trivial change (I'm not even
proposing that this JEP
should include it, just that this would be a good time to release a cancellation
JEP building on this virtual thread JEP), but still the current state is a major
inconvenience. In fact, I just recently learned that, there can be a
scenario where
if you block on an `InputStream` (stdout/stderr of started process) of a started
`Process`, then you will be trapped in the blocking call forever (even
destroy/destroyForcibly of the process won't help), unless you steal and close
the underlying `FileChannel` via reflection.

> As David said, this is more in the area of the (still in draft)
> Structured Concurrency JEP. There have been several prototypes that
> explored the cancellation space. The draft JEP has an explicit non-goal
> to provide a new cancellation mechanism but leaves the door open to
> re-visiting in a future JEP.

I looked up the Structured Concurrency JEP, but the only one I have found
is this draft: https://openjdk.java.net/jeps/8277129 However, this explicitly
states that it will not address the current cancellation issues. That is, there
are a lot of blocking APIs not declaring a thrown `InterruptedException`, and
as far as I can see a JEP addressing cancellation should consider these
cases as well. Can you point me to JEPs / discussion where cancellation
issues were / are being considered?


Thanks,
Attila


More information about the jdk-dev mailing list