RFR: 8291569: Consider removing JNI checks for signals SIGPIPE and SIGXFSZ [v2]

[Robbin Ehn]

On Mon, 23 Jan 2023 00:37:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Simple enhancement to skip checking of the handlers for SIGPIPE and SIGXFSZ as we really don't care if they change, and we expect that they can.
>> 
>> The signal checking code might seem to have a redundancy as we skip these signals in two places, but the primary use of the `do_check_signal_periodically` array is to allow for only issuing one warning per signal. I could have skipped them in either place and get the same effect but it seemed inappropriate to set the array entry and not do the check; and vice-versa.
>> 
>> Testing: just basic sanity test tiers 1-3. This doesn't affect any application behaviour.
>> 
>> There are no regression tests in this specific area and it did not seem worth the effort creating one just for this.
>> 
>> Thanks.
>
> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8291569-signals
>  - 8291569: Consider removing JNI checks for signals SIGPIPE and SIGXFSZ

Hi David, I'm a bit confused here.

Why do we bother with setting up a single handler for i.e. SIGPIPE at all then?
`set_signal_handler(SIGPIPE);`

If the user sets a no-op signal handler for SIGPIPE, without UseSignalChaining, before start of VM we seem to fatal out ?
But if the user sets a no-op signal handler for SIGPIPE after start of VM we do not care?

Isn't this a bit inconsistent?

Shouldn't we just remove SIGPIPE/SIGXFSZ completely if we actually don't care?

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

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