On Tue, 21 May 2024 22:51:14 GMT, Naoto Sato <na...@openjdk.org> wrote:
>> Making sure `restoreEcho` correctly reflects the state in the shutdown >> thread, which differs from the application's thread that issues the >> `readPassword()` method. > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Used a dedicate lock for restoreEcho 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. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19184#issuecomment-2125369806
