JEP 425 (Virtual Threads) - Cancellation

Attila Kelemen attila.kelemen85 at gmail.com
Sun May 1 22:04:09 UTC 2022


Hi,

Since the virtual threads API is currently incubating, I do support that
it should be released (as incubating in Java 19). However, I would
like to propose that a better, more robust cancellation mechanism is to
be provided with it (as some kind of companion JEP) in future releases
before the non-incubating release.

I've always considered the interrupt based cancellation to be very fragile
for various reasons, and I think that the new virtual thread release would
be a very safe time to fix the lack of proper cancellation mechanism in
Java. If it is not fixed before the official release of this JEP, then I fear
that it is less likely to be fixed, due to more compatibility issues. Or if a
new cancellation mechanism will not be released with it, then at least
define the way it is planned to be added in the future to ensure that there
won't be any issues adding it later. The only document I have found
referring to this topic was:
https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part2.html
but it doesn't attempt to address it.

While the cheapness of virtual threads does somewhat solve the issue
of canceling only subtasks by allowing me to start a virtual thread with little
cost, and interrupt it separately, it does not solve other issues. One big
pain of mine is that blocking I/O is often uninterruptible (and not even
cancelable by other means), and as far as I understand, this won't change.

One solution would be of course is to allow providing the virtual threads
a cancellation token upon creation, and let the virtual thread scheduler to
throw a `VirtualThreadCancelledException` (or something similar) in some
well defined cases (definitely not just at any safepoint). Of course, this
exception has to be unchecked, and preferably not extend `Exception`
to avoid people wrapping it left and right. With this the current interruption
mechanism could be deprecated as well.

Can we expect a similar cancellation mechanism to be considered?

Thanks,
Attila


More information about the jdk-dev mailing list