K. On Sun, Feb 27, 2022, 7:03 PM David Holmes <david.hol...@oracle.com> wrote:
> On 28/02/2022 8:20 am, Ethan McCue wrote: > > My understanding is that when you System.exit all threads associated > > with the JVM process are killed. That's what I meant by "nuclear > > Thread.interrupt". > > The process is terminated, the threads are not individually "killed". > All Thread.interrupt does is set a flag and unpark blocked threads (in > some specific cases). There's really no comparison at all. > > David > ----- > > > It's the same issue as was raised about System.exit implicitly ending > > control flow or implicitly closing open file handles - a process could > > be relying on the behavior of implicitly killing all threads and not > > have another cleanup mechanism > > > > On Sun, Feb 27, 2022, 5:16 PM David Holmes <david.hol...@oracle.com > > <mailto:david.hol...@oracle.com>> wrote: > > > > On 28/02/2022 3:20 am, Ethan McCue wrote: > > > I think continuations could work for the single threaded case, > > depending on > > > their behavior with "finally" blocks. I'm sure there are more > > caveats once > > > we add another thread to the mix though. System.exit is a nuclear > > > Thread.interrupt, so replicating that behavior might be a bit > > daunting > > > > What has Thread.interrupt got to do with System.exit ? > > > > David > > > > > private static final class ExitCode { > > > volatile Integer code = null; > > > } > > > > > > private final ScopeLocal<ExitCode> EXIT_CODE = > > ScopeLocal.newInstance(); > > > > > > public void overridingExitBehavior(IntConsumer exit, > > Runnable run) { > > > var exitCode = new ExitCode(); > > > ScopeLocal.with(EXIT_CODE, exitCode).run(() -> { > > > // by whatever syntax > > > var _ = inContinuation(run); > > > if (exitCode.code != null) { > > > exit.accept(code.exitCode) > > > } > > > }); > > > } > > > > > > public void exit(int status) { > > > if (EXIT_CODE.isBound()) { > > > EXIT_CODE.get().code = status; > > > Continuation.yield(); > > > } > > > else { > > > Shutdown.exit(status); > > > } > > > } > > > > > > > > > > > > On Sun, Feb 27, 2022 at 10:41 AM Glavo <zjx001...@gmail.com > > <mailto:zjx001...@gmail.com>> wrote: > > > > > >> I think there is a problem with this: `System.exit` contains > > semantics to > > >> interrupt the flow of control and exit, and if you implement it > > that way, > > >> you might have some program abnormally execute parts of it that > > should > > >> never be executed. > > >> > > >> Of course, using exceptions like this should solve part of the > > problem: > > >> > > >> class Exit extends Error { > > >> final int exitCode; > > >> public Exit(int exitCode) { > > >> this.exitCode = exitCode; > > >> } > > >> > > >> @Override > > >> public synchronized Throwable fillInStackTrace() { > > >> return this; > > >> } > > >> } > > >> > > >> try { > > >> Runtime.getRuntime().overridingExitBehavior(exitCode -> > > {throw new > > >> Exit(exitCode);}, ...); > > >> } catch (Exit exit) { > > >> ... > > >> } > > >> > > >> However, the calling method may catch this exception > > unexpectedly, and > > >> there may be unexpected behavior under multithreading. > > >> Of course, this part of the problem also exists for the security > > manager. > > >> But, if possible, it would be better to have a solution for these > > >> situations. > > >> (`Continuation` might help us?) > > >> > > >> > > >> > > >> On Sun, Feb 27, 2022 at 11:07 PM Ethan McCue <et...@mccue.dev > > <mailto:et...@mccue.dev>> wrote: > > >> > > >>> That undermines my point some, but I think the overall shape of > > the use > > >>> case still makes sense > > >>> > > >>> On Sun, Feb 27, 2022 at 8:01 AM Remi Forax <fo...@univ-mlv.fr > > <mailto:fo...@univ-mlv.fr>> wrote: > > >>> > > >>>> Hi Ethan, > > >>>> there is a far simpler solution, call org.apache.ivy.run(args, > > true) > > >>>> instead of org.apache.ivy.main(args) in your tool provider. > > >>>> > > >>>> regards, > > >>>> Rémi > > >>>> > > >>>> ----- Original Message ----- > > >>>>> From: "Ethan McCue" <et...@mccue.dev <mailto:et...@mccue.dev > >> > > >>>>> To: "core-libs-dev" <core-libs-dev@openjdk.java.net > > <mailto:core-libs-dev@openjdk.java.net>> > > >>>>> Sent: Saturday, February 26, 2022 11:14:19 PM > > >>>>> Subject: Should System.exit be controlled by a Scope Local? > > >>>> > > >>>>> I have a feeling this has been considered and I might just be > > >>>> articulating > > >>>>> the obvious - but: > > >>>>> > > >>>>> As called out in JEP 411, one of the remaining legitimate > > uses of the > > >>>>> Security Manager is to intercept calls to System.exit. This > seems > > >>> like a > > >>>>> decent use case for the Scope Local mechanism. > > >>>>> > > >>>>> > > >>>>> public class Runtime { > > >>>>> ... > > >>>>> private final ScopeLocal<IntConsumer> EXIT = > > >>>>> ScopeLocal.newInstance(); > > >>>>> > > >>>>> ... > > >>>>> > > >>>>> public void overridingExitBehavior(IntConsumer exit, > > Runnable > > >>>> run) { > > >>>>> ScopeLocal.with(EXIT, exit).run(run); > > >>>>> } > > >>>>> > > >>>>> ... > > >>>>> > > >>>>> public void exit(int status) { > > >>>>> if (EXIT.isBound()) { > > >>>>> EXIT.get().accept(status); > > >>>>> } > > >>>>> else { > > >>>>> Shutdown.exit(status); > > >>>>> } > > >>>>> } > > >>>>> } > > >>>>> > > >>>>> > > >>>>> One of the likely minor benefits in the scope of things, but > > related > > >>> to > > >>>> the > > >>>>> parts of the ecosystem I am doodling with so I'll mention it, > > is that > > >>> it > > >>>>> would become possible to wrap "naive" cli programs with the > > >>> ToolProvider > > >>>>> SPI without rewriting their code if this System.out, and > > System.err > > >>> all > > >>>>> became reliably configurable. > > >>>>> > > >>>>> For instance, Apache Ivy's CLI has a main class that looks > > like this > > >>>>> > > >>>>> > > >>>> > > >>> > > > https://github.com/apache/ant-ivy/blob/424fa89419147f50a41b4bdc665d8ea92b5da516/src/java/org/apache/ivy/Main.java > > < > https://github.com/apache/ant-ivy/blob/424fa89419147f50a41b4bdc665d8ea92b5da516/src/java/org/apache/ivy/Main.java > > > > >>>>> > > >>>>> package org.apache.ivy; > > >>>>> > > >>>>> public final class Main { > > >>>>> ... > > >>>>> > > >>>>> public static void main(String[] args) throws > Exception { > > >>>>> try { > > >>>>> run(args, true); > > >>>>> System.exit(0); > > >>>>> } catch (ParseException ex) { > > >>>>> System.err.println(ex.getMessage()); > > >>>>> System.exit(1); > > >>>>> } > > >>>>> } > > >>>>> } > > >>>>> > > >>>>> Making these otherwise static parts of the system > > configurable would > > >>>> enable > > >>>>> a third party library to write > > >>>>> > > >>>>> public final class IvyToolProvider implements > ToolProvider { > > >>>>> @Override > > >>>>> public String name() { > > >>>>> return "ivy"; > > >>>>> } > > >>>>> > > >>>>> @Override > > >>>>> public int run(PrintWriter out, PrintWriter err, > > String... > > >>> args) { > > >>>>> var exit = new AtomicInteger(0); > > >>>>> > > Runtime.getRuntime().overridingExitBehavior(exit::set, () > > >>> -> { > > >>>>> System.overridingOut(out, () -> { > > >>>>> System.overridingErr(err, Main::main); > > >>>>> } > > >>>>> }; > > >>>>> return exit.get(); > > >>>>> } > > >>>>> } > > >>>>> > > >>>>> Whether that would be enough to make it so that people other > than > > >>>> Christian > > >>>>> Stein use the mechanism is anyone's guess, but might be worth > > a shot. > > >>>>> > > >>>>> https://grep.app/search?q=java.util.spi.ToolProvider > > <https://grep.app/search?q=java.util.spi.ToolProvider> > > >>>> > > >>> > > >> > > >
