On Thu, 20 Jan 2022 20:11:43 GMT, Xin Liu <x...@openjdk.org> wrote:
>> src/hotspot/os/posix/signals_posix.cpp line 600:
>>
>>> 598: assert(!ReduceSignalUsage, "Should not happen with
>>> -Xrs/-XX:+ReduceSignalUsage");
>>> 599: signal_was_handled = true;
>>> 600: }
>>
>> Can't we just do this as the very first thing at line 564:
>>
>> // If we get BREAK_SIGNAL it means we are very early in VM initialization
>> and
>> // only temporarily "handling" it to prevent the VM process getting
>> terminated.
>> if (sig == BREAK_SIGNAL) {
>> assert(!ReduceSignalUsage, "Should not happen with
>> -Xrs/-XX:+ReduceSignalUsage");
>> return true;
>> }
>
> hi, David and Thomas,
>
> I am nervous about this change. It's not complex but I don't want to break
> the existing java applications. Bear with me.
>
> From my reading, HotSpot can chain a user-custom signal handler because of
> libjsig.so. It's not like a linked-list chain. if the user installs a
> handler for a signal, libjsig just saves it. JVM_HANDLE_XXX_SIGNAL is invoked
> first and then the user-custom handler is called
> [here](https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/signals_posix.cpp#L635)
> if it isn't handled.
>
> The reason we can hoist this logic to line 564 because we **assume** that no
> user application would define a handler for BREAK_SIGNAL. It doesn't work
> right now because os::initialize_jdk_signal_support() will overwrite the
> signal handler of BREAK_SIGNAL later.
Hi Xin,
Signal chaining doesn't work for BREAK_SIGNAL - from the signal chaining docs:
Note:
The SIGQUIT, SIGTERM, SIGINT, and SIGHUP signals cannot be chained. If the
application must
handle these signals, then consider using the —Xrs option.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7003
