On Tue, 5 Jul 2022 04:47:40 GMT, Ryan Ernst <d...@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
