Should System.exit be controlled by a Scope Local?

[David Holmes]

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 <zjx001202 at 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 <ethan at 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 <forax at 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" <ethan at mccue.dev>
>>>>> To: "core-libs-dev" <core-libs-dev at 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
>>>>>
>>>>>     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
>>>>
>>>
>>