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

[Thomas Stuefe]

On Tue, 24 Jan 2023 13:33:29 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> 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
>
> Now pieces fall into place. I totally forgot about libjsig.
> 
> Thank you for your patience :) !
> 
> Seems reasonable to me also!

> And just to be clear @robehn the scenario we are dealing with is the case where libjsig is not actually used - as we would not install the user's handler in that case we would chain to it. See:
> 
> https://bugs.openjdk.org/browse/JDK-8292054
> 
> for the kind of scenario (though for different signals). So we do rely on the third-party code doing the right thing by taking over the handler temporarily and then restoring it - if they don't then yes we can crash.
> 
> So that said I'm now second-guessing the approach here:
> 
>     * pro: doesn't issue a warning for a well-behaved third-party library that messes with the handler
> 
>     * con:  doesn't issue a warning for a badly-behaved third-party library that messes with the handler and triggers a crash

I'm fine with both approaches.

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

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