RFR: 8226816: add UserHandler calls to event log

[David Holmes]

On 4/07/2019 11:06 pm, Baesken, Matthias wrote:
> Hi David,  thanks for looking into this .
> 
>>
>> If you add this then we don't need distinct POSIX and non-POSIX versions
>> - the existing os::Posix::get_signal_name etc could all be hoisted into
>> os.cpp and the os class - no?
>>
> 
> Should I go for this ?
> The coding is still a little different   (e.g. is_valid_signal (.. ) call  in os_posix )  but I think it could be done without much trouble (maybe with a few small ifdefs ) .

I think it's worth trying it.

I have to apologize in advance though as I'm about to disappear on two 
weeks vacation so may not be able to follow through on this.

Thanks,
David

> 
>> That's a LinuxThreads anachronism which has been copied, unnecessarily
>> into the other OS implementations. I will file a RFE to get rid of it.
> 
> Good catch !
> 
> Best regards, Matthias
> 
>>
>> Hi Matthias,
>>
>> On 27/06/2019 6:56 pm, Baesken, Matthias wrote:
>>> Hello, please review  the following  small  patch .
>>> It adds  event logging to  the UserHandler  (user signal handler) calls .
>>
>> That seems reasonable.
>>
>>> (additionally  it adds   a function   os::win32::get_signal_name
>>> to get  signal names for signal numbers ; this is similar to what we already
>> had for posix ).
>>
>> If you add this then we don't need distinct POSIX and non-POSIX versions
>> - the existing os::Posix::get_signal_name etc could all be hoisted into
>> os.cpp and the os class - no?
>>
>> Aside: I spotted this in UserHandler:
>>
>>       // 4511530 - sem_post is serialized and handled by the manager
>> thread. When
>>       // the program is interrupted by Ctrl-C, SIGINT is sent to every
>> thread. We
>>       // don't want to flood the manager thread with sem_post requests.
>>       if (sig == SIGINT && Atomic::add(1, &sigint_count) > 1)
>>         return;
>>
>> That's a LinuxThreads anachronism which has been copied, unnecessarily
>> into the other OS implementations. I will file a RFE to get rid of it.
>>
>> Thanks,
>> David
>>
>>>
>>>
>>> Bug/webrev :
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8226816
>>>
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8226816.0/
>>>
>>> Thanks, Matthias
>>>