Can continuation support finally solve the "How do I stop this thread" problem?

Alan Bateman Alan.Bateman at
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 <> 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 | 
> <>| 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 

> :
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the loom-dev mailing list