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