RFR 9: 8087286 Need a way to handle control-C and possibly some other signals

[Roger Riggs]

Hi Peter,

I'll take a deeper look tomorrow,  I spent some time today updating my 
prototype with the suggestions.
And there is more to iterate over tomorrow.

Updated webrev:
    http://cr.openjdk.java.net/~rriggs/webrev-signal-8087286/

...

On 2/2/2016 3:58 PM, Peter Levart wrote:
>
>
> On 02/02/2016 05:45 PM, Roger Riggs wrote:
>> Hi Peter,
>>
>>
>> On 2/2/2016 11:14 AM, Peter Levart wrote:
>>> Hi Roger,
>>>
>>> On 02/02/2016 04:16 PM, Roger Riggs wrote:
>>>> Hi Peter,
>>>>
>>>> On 2/2/2016 6:44 AM, Peter Levart wrote:
>>>>>
>>>> ...
>>>>>
>>>>> Also if this is to become public API, There's a chance users would 
>>>>> want to add a handler to the chain of existing handlers or 
>>>>> override them. So what about an API that allows 
>>>>> registering/unregistering a default (non-native) handler and other 
>>>>> handlers above it in a uniform way, like:
>>>> The problem with chaining, as in the current API, is that there is 
>>>> no way to know what the next
>>>> handler in the chain will do.  If it is the default one for INT, 
>>>> TERM, HUP, it will call Shutdown and exit.
>>>> So without extra information and cooperation chaining is risky.
>>>> If the handler knows something about the other actors in the 
>>>> environment, it can coordinate with them directly.
>>>> For the use cases that have been raised for existing use of 
>>>> sun.misc.Signal, they are simple interactive
>>>> environments that want to give the appearance of being able to 
>>>> interrupt using control-c.
>>>>
>>>> I've been aiming for the simplest API that would support the 
>>>> current use cases.
>>>
>>> I noticed that sun.misc.Signal[Handler] is a critical API according 
>>> to JEP 260, so it can't be removed in JDK9 yet. I wanted to see if 
>>> sun.misc.Signal[Handler] could be modified to use java.util.Signal 
>>> directly while making java.util.Signal support chaining and 
>>> restoring of previous handler on deregister. Here's what it looks 
>>> like in code:
>>>
>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Signal/webrev.01/
>>>
>>> But if chaining is not desired, then at least restoring of previous 
>>> handler could be implemented in a uniform way and for arbitrary 
>>> registration depth (no need for register/registerDefault distinction).
>>
>> A stack based model can work but still needs backup handlers for when 
>> all the specified handlers to unregistered.
>> I'm ok with submerging registerDefault into the implementation used 
>> only by the system Termination class.
>> I don't think the use cases call for a stack and it makes the API 
>> more complex for register/unregister.
>>
>> I'd rather see a good simple j.u.Signal API that meets the 
>> requirements without considering how to
>> support the legacy s.m.Signal, if it needs a bit of cruft to support 
>> it for a while that's ok.
>> Someday we will want to rip out all that code and have a simple API.
>
> Here's another attempt that removes the possibility to chain handlers, 
> but keeps a stack of previous handlers so that unregistration returns 
> to exactly the same state as before registration. j.l.System can 
> therefore use plain register() method for the default handlers and 
> nesting registrations/unregistrations are possible:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/Signal/webrev.02/
>
> The API is practically the same as your's with the exception of the 
> specification of unregister() which documents the restoration of 
> previous state and does not mention any "default" handlers.
>
> The implementation is much simpler now (counting the lines of 
> NativeSignal interface + j.u.Singnal class vs. your SignalImpl + 
> j.u.Signal results in 392 vs. 513)
It looks interesting, though a different style implementation.
And I'd rather use mundane synchronization primitives that keep the code 
easier to read, even if a bit less optimized.

Thanks, Roger

>
> What do you think?
>
>
> Regards, Peter
>
>>