RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work with signal chaining library [v4]

[David Holmes]

On Tue, 20 Sep 2022 05:26:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Messing around with initialization order always makes me very nervous. While this may have solved the problem at hand it is far from clear to me that it has not introduced unexpected behaviour in other situations - situations that our testing is unlikely to expose.
>
>> Messing around with initialization order always makes me very nervous. While this may have solved the problem at hand it is far from clear to me that it has not introduced unexpected behaviour in other situations - situations that our testing is unlikely to expose.
> 
> Hmm, we put a lot of work and time into this solution. While I acknowledge this is a difficult area, so are many others in hotspot which we are not shy of changing. And we did not change the coding on a whim - the proposed solution IMHO is better than the assortment of piled-on hotfixes we had before and dissolves quite a bit of complexity. That makes the code easier to understand and maintain in the long run. @caoman also provided a regression test, so that's covered too.
> 
> But if you have concrete misgivings about the proposed solution, let's discuss it.

@tstuefe IIUC the earlier proposal from @caoman  simply moved the setting of the BREAK_HANDLER to inside `jdk_misc_signal_init`. But you then had it moved instead to `install_signal_handlers`, which then required that `install_signal_handlers` get moved after `jdk_misc_signal_init` as the `UserHandler` depends on initialization that occurs there. I don't understand why that complex double-shuffle was needed/wanted instead of what Man proposed??

-------------

PR: https://git.openjdk.org/jdk/pull/9955