On Wed, 22 May 2024 17:20:02 GMT, Naoto Sato <na...@openjdk.org> wrote:
> Hi Pavel, > > > If I read > > [this](https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Runtime.html#shutdown) > > correctly, due to the mechanics of JVM exit, we simply don't know which > > thread finishes first: a thread that calls `readPassword` or the shutdown > > hook. > > IIUC, the thread that waits on `readPassword()` is not a shutdown hook, > right? Then I think it is guaranteed that it is still waiting when all the > shutdown hooks are executed. > > > If the shutdown hook finishes first, then a `readPassword` thread can > > corrupt the state: unlike the shutdown hook, which JVM _normally has to > > wait to complete_, the `readPassword` thread can be terminated at any > > moment. It might as well be terminated before `finally` but after > > `echo(false)`, in which case we end up with echo turned off. > > After the shutdown hooks finish, then the VM is terminated > (https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Runtime.html#termination). > In there: > > ``` > finally clauses are not executed; > ``` > > So I think the shutdown hook's restoreEcho has the final say, sans the > situation if some app installs a shutdown hook with `readPassword` but I > don't think we can guarantee that case, and I believe it is OK. I might be confused, but what if the shutdown hook completes and then some application thread enters `readPassword`. If that thread manages to turn off echo before all other shutdown hooks complete, it might never execute `finally`, hence a race. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19184#issuecomment-2125497081
