Can continuation support finally solve the "How do I stop this thread" problem?
Alan Bateman
Alan.Bateman at oracle.com
Thu Sep 1 07:04:26 UTC 2022
On 31/08/2022 22:50, Archie Cobbs wrote:
> :.
>
> The term "sandbox" has various meanings but for this question think of
> it simply as what you would need (for example) to build a web site
> that hosted a live JShell console for educational purposes but all
> running within a single JVM (there are some examples of this out there
> like tryjshell.org <http://tryjshell.org> but those use separate
> processes or Docker).
Using containers and the isolation features provided by the operating
system seems the right thing to do there.
> :
>
>
> > The implementations of the networking APIs in the |java.net
> <http://java.net>| and |java.nio.channels| packages now work with
> virtual threads: An operation on a virtual thread that blocks to,
> e.g., establish a network connection or read from a socket, releases
> the underlying platform thread to do other work.
>
> This makes it sounds like basically every blocking method is going to
> have to be adapted so that its state can be "detached" from the
> platform thread for continuation purposes...? If so, great!
>
> My question is this: could this work be leveraged to also finally
> solve the "How do I stop this thread" problem?
>
> Even if this new mechanism only worked for virtual threads (or only
> for platform threads) it would still be a big improvement.
That mechanism is Thread.interrupt. Interruptible channels were added in
Java 1.4 so that interrupting a Thread blocked on a channel will cause
the channel to be closed and the Thread to throw an exception. That has
been extended to the legacy network APIs so that if a virtual thread
blocked on a Socket or http URL connection or whatever, then
interrupting it will cause the underlying socket to be safely closed and
the Throw to throw an exception. So I think it should help with your
scenario. In general, using Thread.interrupt for cancellation relies on
careful handling and testing of the interrupt threads - if something
ignores/swallows the interrupt status then the Thread may not terminate
quickly.
>
> :
>
> On a related note - will [JEP 428 Structured Concurrency] guarantee
> that exiting a StructuredTaskScope never hangs indefinitely?? I guess
> not..
A non-responsive sub-task could mean the owner blocks in close indefinitely.
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20220901/b390bacb/attachment-0001.htm>
More information about the loom-dev
mailing list