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

[Alan Bateman]

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>