<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
On 31/08/2022 22:50, Archie Cobbs wrote:<br>
<blockquote type="cite" cite="mid:CANSoFxuYQgrHtjEGbRWEJr3f3p3VDDwGnJ1DX4PsSAQxoND-kw@mail.gmail.com">
<div dir="ltr">:.<br>
<div><br>
</div>
<div>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 <a href="http://tryjshell.org" moz-do-not-send="true">tryjshell.org</a>
but those use separate processes or Docker). </div>
</div>
</blockquote>
<br>
Using containers and the isolation features provided by the
operating system seems the right thing to do there.<br>
<br>
<br>
<blockquote type="cite" cite="mid:CANSoFxuYQgrHtjEGbRWEJr3f3p3VDDwGnJ1DX4PsSAQxoND-kw@mail.gmail.com">
<div dir="ltr">
<div>:<br>
</div>
<br>
<div><br>
</div>
<div>> The implementations of the networking APIs in <span style="font-family:arial,sans-serif">the <code><a href="http://java.net" moz-do-not-send="true">java.net</a></code>
and <span style="font-family:arial,sans-serif"><code>java.nio.channels</code></span>
pa</span>ckages 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.</div>
<div><br>
</div>
<div>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! </div>
<div><br>
</div>
<div>My question is this: could this work be leveraged to also
finally solve the "How do I stop this thread" problem?<br>
</div>
<br>
<div>Even if this new mechanism only worked for virtual threads
(or only for platform threads) it would still be a big
improvement. <br>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote type="cite" cite="mid:CANSoFxuYQgrHtjEGbRWEJr3f3p3VDDwGnJ1DX4PsSAQxoND-kw@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>:<br>
</div>
<div><br>
<div>
<div>On a related note - will [JEP 428 Structured
Concurrency] guarantee that exiting a StructuredTaskScope
never hangs indefinitely?? I guess not.. </div>
</div>
</div>
</div>
</blockquote>
<br>
A non-responsive sub-task could mean the owner blocks in close
indefinitely.<br>
<br>
-Alan<br>
</body>
</html>