Ok, you're right that it can raise an exception when the calling thread does
not have the security privileges needed. But what if it had them ? Right now
the deadlock comes from the fact is doesn't got back to the caller with an
exception and doesn't end the current thread. My 1st proposal was to have a way
to end the current thread. If you think that is not acceptable and prefer the
exception solution, then something like throw new
IllegalStateException("Shutdown in progress") which is already used when adding
new hooks while shutting down and adjust the System.exit method documentation
accordingly (might be dangerous since it "breaks" actual documented and
implemented contract, might be too heavy for a change).
First things first : do you think this is an issue the JVM has to solve (either
using a destroy-current-thread solution, or a throw-IllegalStateException one),
or do you think this was a hook misuse and maybe would only need maybe a
clearer warning in the hooks's documentation, or do you think we keep
everything as it is because I should have guessed better reading the actual
documentation 😊 ?
My demo code is simple, but the environment in which it happened and being able
to understand the jstack output with lots of frameworks hooking here and there
plus some uncaught exception hanlders kicking in was really really hard. In my
case I ended up having a hook to run a delayed Runtime.halt call, which more
feels like a JVM workaround rather than a framework workaround.
Regards,
Orange Restricted
-----Message d'origine-----
De : David Lloyd <david.ll...@redhat.com>
Envoyé : lundi 25 avril 2022 15:41
À : CATHERINOT Rémi DTSI/PFS <remi.catheri...@orange.com>
Cc : core-libs-dev@openjdk.java.net
Objet : Re: System.exit deadlock if called within a hook
On Mon, Apr 25, 2022 at 8:09 AM <remi.catheri...@orange.com> wrote:
> because it would still run finally blocks, which cannot happen for no
> return methods like System.exit and Runtime.halt
FWIW I don't think this is correct. `exit` and `halt` etc. cannot
*return* but they're definitely allowed to throw an exception
(`SecurityException` is presently specified) and thus are allowed to unwind the
stack, even through `finally` blocks.
--
- DML • he/him
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
