RFR 9: 8087286 Need a way to handle control-C and possibly some other signals
Roger.Riggs at Oracle.com
Tue Feb 2 23:14:12 UTC 2016
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.
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:
>>> 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:
> 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.
> What do you think?
> Regards, Peter
More information about the core-libs-dev