<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div class="">Hi.</div>
<div class=""><br class="">
</div>
See Alan’s response re the details of interruption.
<div class=""><br class="">
</div>
<div class="">When it comes to the question of forcibly killing threads, for it to be generally useful, there must be limitations imposed on what the threads can do to data that is accessed by other threads, as an errant thread could otherwise harm other threads.
The Java platform (and language) currently does not impose such “isolation” limitation, but some language targeting the Java platform could, and so it could also emit interruption checks when compiling to bytecode. A language that behaves in this way is Erlang
(although I don’t know if implementations targeting Java are currently maintained), but even there there are pitfalls. A similar path is available to jshell as well, as it can emit interruption checks in the bytecode.</div>
<div class=""><br class="">
</div>
<div class="">As to the question of sandboxing in general, I believe the best way is to restrict the APIs available to untrusted code. Modules are one part of the story, but the java.base module, available to all Java programs, has plenty of “dangerous" APIs.
Those could be fenced off with (very careful!) bytecode transformation and classloader implementation. However, just as sandboxing of Java code requires some support from the Java runtime, when native code is involved — perhaps even indirectly — sandboxing
would require support from the OS, and the OS does provide “isolates” in the form of processes. Forcibly terminating a process is *largely* safe (assuming the process is forbidden from mutating shared files or memory).</div>
<div class=""><br class="">
</div>
<div class="">But note that while the Java runtime is, at least hypothetically, able to provide sandboxing for a *client* program (such as applets), it lacks other crucial pieces to support sandboxing of *server* programs. The difference between the two is
that client programs implicitly rely on OS process isolation: a client program serves one user, while a server program of the kind you describe serves many. Even if all “dangerous” APIs are blocked, any user code could allocate as much memory as it likes,
exhausting the memory available for the entire process. If it is also allowed to spawn platform threads at will, it can also exhaust the CPU allocation for the entire process. In the case of a client program, the process can be forcibly terminated without
affecting other users, but that is not the case for server programs that are shared among multiple users.</div>
<div class=""><br class="">
</div>
<div class="">The Java runtime could be changed to support isolated heaps in imitations of the isolation and memory restrictions offered by the OS, but if the goal is to share some internal runtime data structures for efficiency, there are ways to do that for
multiple processes. Given that the kernel has more arrows in its quiver to support such isolation, including at the native code level, that is probably the most appropriate level to provide it, I think, so much so that trying to implement proper and secure
isolation in multi-user server programs in user mode is a fool’s errand. A multi-user Java runtime running in *kernel* mode is a different matter altogether, but it is currently beyond the scope of the OpenJDK JDK.</div>
<div class=""><br class="">
</div>
<div class="">— Ron<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 31 Aug 2022, at 22:50, Archie Cobbs <<a href="mailto:archie.cobbs@gmail.com" class="">archie.cobbs@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div class="">This question is somewhat tangential to Loom but I thought I'd ask in case the answer is an easy yes or no.<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">Lately I've been reviewing various attempts at intra-JVM Java "sandboxing", none of which are fully satisfying. I think this is a missed opportunity for Java in general, but that's a separate discussion.<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">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/" class="">tryjshell.org</a> but those use separate processes or Docker). Obviously, execution of arbitrary Java code from random people on the Internet would have to be strictly controlled,
and therefore JShell's ExecutionControl would have to run the code in some kind of airtight sandbox.<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">I just want to focus on one small aspect of doing this: A basic requirement of such a sandbox is the ability to stop a running thread. But currently there's no 100% reliable way to do this in Java, even if you can rewrite the bytecode, because
it's impossible to unblock a thread blocked in certain system calls.<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">What about Thread.stop()? It only works sometimes. Plus it's deprecated (side node, the stated reasons for deprecating this method never made sense to me, because the trade-offs should be left to the programmer to evaluate, and moreover ThreadDeath
is no more unsafe than StackOverflowError, which programmers seem to throw all the time :)<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">FYI here's a simple example showing a thread that can't be stopped no matter what we try:<br class="">
</div>
<div class=""><br class="">
<div style="margin-left:40px" class="">public class ThreadNoStop {<br class="">
public static void main(String[] args) throws Exception {<br class="">
<br class="">
// Start unstoppable thread<br class="">
final Thread thread = new Thread(() -> {<br class="">
System.out.println("thread: reading stdin...");<br class="">
try {<br class="">
System.in.read();<br class="">
} catch (Throwable t) {<br class="">
System.out.println("thread: caught exception: " + t);<br class="">
}<br class="">
System.out.println("thread: done reading stdin...");<br class="">
});<br class="">
thread.start();<br class="">
<br class="">
// Try to kill it any way possible<br class="">
Thread.sleep(500);<br class="">
System.out.println("main: invoking interrupt()...");<br class="">
thread.interrupt();<br class="">
System.out.println("main: invoking stop()...");<br class="">
thread.stop();<br class="">
System.out.println("main: closing System.in...");<br class="">
System.in.close(); // hangs here until there's input<br class="">
System.out.println("main: joining thread...");<br class="">
thread.join();<br class="">
System.out.println("main: done.");<br class="">
}<br class="">
}<br class="">
</div>
</div>
<div class=""><br class="">
</div>
<div class="">[JEP 425 Virtual Threads] states:<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">> The implementations of the networking APIs in <span style="font-family:arial,sans-serif" class="">
the <code class=""><a href="http://java.net/" class="">java.net</a></code> and <span style="font-family:arial,sans-serif" class="">
<code class="">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 class=""><br class="">
</div>
<div class="">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 class=""><br class="">
</div>
<div class="">My question is this: could this work be leveraged to also finally solve the "How do I stop this thread" problem?<br class="">
</div>
<br class="">
<div class="">Even if this new mechanism only worked for virtual threads (or only for platform threads) it would still be a big improvement.
<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">Again, my opinion here but it seems like there really ought to be some official equivalent of Process.destroyForcibly() for Java threads.... it's a basic control/fail-safe.<br class="">
</div>
<div class=""><br class="">
<div class="">
<div class="">On a related note - will [JEP 428 Structured Concurrency] guarantee that exiting a StructuredTaskScope never hangs indefinitely?? I guess not..
</div>
<div class=""><br class="">
</div>
<div class="">But a better stop mechanism would allow it to make that nice guarantee. This would give it an "automatic cleanup" feature analogous to how try-with-resources automatically hides any extra exceptions thrown by close().</div>
<div class=""><br class="">
</div>
<div class="">We could also then add a new method ExecutorService.forceShutdown()...</div>
<div class=""><br class="">
</div>
<div class="">This seems like an obvious missing piece to me.<br class="">
</div>
</div>
<div class=""><br class="">
</div>
<div class="">Thoughts?</div>
<div class=""><br class="">
</div>
</div>
<div class="">-Archie</div>
<div class=""><br class="">
</div>
<div class="">-- <br class="">
<div dir="ltr" data-smartmail="gmail_signature" class="">Archie L. Cobbs<br class="">
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>