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
