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

David Holmes dholmes at openjdk.org
Tue Jul 5 07:28:37 UTC 2022


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

>> YAO (Yet Another Opinion)!  But I think we're actually converging.
>> 
>> David's wording:
>>>Invocations of this method are serialized such that only one invocation will actually proceed with the shutdown sequence and terminate the VM with the given status code.
>> 
>> ... gives the impression that an invocation of this method WILL terminate the VM with the given status code - which is not actually true, given the potential for signals. This is already alluded to in `Runtime::addShutdownHook`. I agree that this could be resolved separately, but we should _allow_ for signals (even if we don't explicitly mention them).
>>  
>> The original wording:
>>> If this method is invoked after all shutdown hooks have already been run ... 
>> 
>> ... seems quite clever (and allows for signals). Maybe we could keep things super simple:
>>> If this method is invoked after shutdown hooks have already been started, it will block indefinitely. If this method is invoked from a shutdown hook the system will deadlock.
>
> I like the new suggested wording, but I would slightly tweak it. As Alan mentioned in another comment the first paragraph makes clear the method never returns normally. How does the following sound?
> 
>> If this method is invoked after shutdown hooks have already been started, the supplied status code will be ignored. If this method is invoked from a shutdown hook the system will deadlock.

> gives the impression that an invocation of this method WILL terminate the VM with the given status code - which is not actually true, given the potential for signals.

The subtle distinction being calling Runtime.exit versus Shutdown.exit. The actual serialization takes places in Shutdown.exit and serializes with signals too. But discussion of signals has no place here - I'm not even sure we document those ways of terminating the VM anywhere?

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

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


More information about the core-libs-dev mailing list