RFR: 8332084: Ensure JdkConsoleImpl.restoreEcho visibility in a shutdown hook [v8]

Naoto Sato naoto at openjdk.org
Wed May 22 17:23:15 UTC 2024


On Tue, 21 May 2024 22:51:14 GMT, Naoto Sato <naoto at 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


More information about the core-libs-dev mailing list