RFR: 8295125: os::signal should be os specific

[David Holmes]

On Sat, 29 Oct 2022 12:16:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This was intended as a significant cleanup RFE but it turned out things were a lot messier than initially envisaged, so the resultant cleanup is quite limited.
>> 
>> The OS API/namespace was simplified by removing three signal related functions that are not needed in shared code:
>>  - signal
>>  - user_handler
>>  - raise
>> The first two were reworked and placed into PosixSignals and os::win32.
>> There was no need for a specific XX::raise API as os::raise simply called ::raise.
>> 
>> On the Posix side we had the basic signal handler installation code in two places:
>> 
>> 1. Inline in set_signal_handler and used by nearly all the VM signals
>> 2. In os::signal which was used by three different "clients"
>>   - VM error handler for updating crash handler
>>   - VM for installing SIG_BREAK handler
>>   - JDK via JVM_RegisterSignal
>> 
>> This was refactored so that we have:
>> 
>> 1. PosixSignals::install_sigaction_signal_handler
>>   - used by the VM only
>>     - set_signal_handler
>>     - VM error handler for updating crash handler
>>     - VM for installing SIG_BREAK handler
>> 
>> 2. PosixSignals::install_generic_signal_handler
>>   - used by JDK via JVM_RegisterSignal
>> 
>> The sigaction handlers were all consistently defined as per the posix definition:
>>     void func(int signo, siginfo_t *info, void *context);
>>   
>> 
>> On the Windows side we just fixed the incorrect definition of UserHandler and made some consistency changes to use the right signal handler type where possible.
>> 
>> Thanks.
>
> I'm loath to say "looks good", but looks okay for what it is.
> 
> Fixing JDK-8295702 will likely involve some refactoring of what's here. But
> that's a problem for the next person who pokes at this tar baby.

Thanks @kimbarrett !

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

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