RFR: 8288984: Simplification in Shutdown.exit [v3]

[David Holmes]

On Tue, 5 Jul 2022 04:47:40 GMT, Ryan Ernst <duke at openjdk.org> wrote:

>> First, the signal handlers actually invoke Shutdown.exit, not Shutdown.shutdown  - see Terminator.setup(). (If they did the latter, like DestroyJavaVM, then an exit(status) call from another thread could still do the final VM halt(status)
>> 
>> But now you are opening a can of worms. There are multiple ways for the VM to initiate termination - are you going to try and describe here how all of them potentially interact?  
>> 
>> What you are really stating here is that other parts of the JDK can invoke System.exit, but that is for them to specify where such things are specified, it isn't for exit() to try and list them all. All we have to do here is describe how multiple calls to exit() behave.
>
> Aha! I think I misread the comment on Shutdown.shutdown and had it stuck in my head that signals would exit through that method. Thanks for the explanation, it makes a lot more sense now.
> 
>> All we have to do here is describe how multiple calls to exit() behave.
> 
> The thing that is still missing to me is that an application developer may have a single call to System.exit, yet the status code they pass to it may not be the one the jvm exits with.

Yes and the problem is? If the user kills the VM by other means; or the termination of the last non-daemon thread races with a call to System.exit then the developer doesn't really have to right to expect anything in relation to that one call.

-------------

PR: https://git.openjdk.org/jdk/pull/9351