RFR: 8303198: System and Runtime.exit() resilience to logging errors
Roger Riggs
rriggs at openjdk.org
Mon Feb 27 23:23:07 UTC 2023
On Mon, 27 Feb 2023 23:00:45 GMT, David Holmes <dholmes at openjdk.org> wrote:
>> Yes, its racy, and intentional, but from a diagnostic view, the developer should know that multiple callers were trying to exit. All but one will hang.
>> Consolidating the code in a single method is cleaner and with fewer interactions between separate code blocks.
>
> I can't tell if the thread identity will be included in the log the message?
>
> I'm not so sure it is useful to allow competing exit calls to all log their intent. I would have kept the logging itself inside the locked region as per the original code.
The main diagnostic is the logged message with the stack trace. The println version is present as a diagnostic if logging is mis-configured.
If the developer is looking to mitigate calls to Runtime.Exit, then they are advised to check all paths and will appreciate not having to wait for a different thread to win the race.
-------------
PR: https://git.openjdk.org/jdk/pull/12770
More information about the core-libs-dev
mailing list