hi Roger, I love that we are adding this Signal object. I have several questions, but please do not take them as criticism, I’m just seeking clarification and providing feedback:
#1 Re: "Consumers for signals that are unknown or reserved by the Java implementation can not be registered.” - Why don't we want to allow unknown signals? This will make us have to update our implementation if we want to support new or platform specific signals in the future. #2 Re: "java.util.Signal.raise()” - That API raises the signal in the current process, but what about sending a signal to another process for interprocess communication? #3 Re: "Signal.of("SIGINT”)” - Is this a factory method that returns the same object if called more than once? #4 Re: "public boolean unregister(Consumer<Signal> consumer)” - Why is this API returning a value? Wouldn’t having a Signal API like “public Consumer<Signal> getConsumer()” be more flexible? #5 Re: "public void registerDefault(Consumer<Signal> consumer)” - Do we really need this API? Can’t the same be achieved with the plain vanilla “public void register(Consumer<Signal> consumer)” I guess I don’t really see what makes this API special. cheers > On Feb 1, 2016, at 10:02 AM, Roger Riggs <roger.ri...@oracle.com> wrote: > > Please review an API addition to handle signals such as SIGINT, SIGHUP, and > SIGTERM. > This JEP 260 motivated alternative to sun.misc.Signal supports the use case > for > interactive applications that need to handle Control-C and other signals. > > The new java.util.Signal class provides a settable primary signal handler and > a default > signal handler. The primary signal handler can be unregistered and handling > is restored > to the default signal handler. System initialization registers default > signal handlers > to terminate on SIGINT, SIGHUP, and SIGTERM. Use of the Signal API requires > a permission if a SecurityManager is set. > > The sun.misc.Signal implementation is modified to be layered on a common > thread and dispatch mechanism. The VM handling of native signals is not > affected. > The command option to reduce signal use by the runtime with -Xrs is > unmodified. > > The changes to hotspot are minimal to rename the hardcoded callback to the > Java > Signal dispatcher. > > Please review and comment on the API and implementation. > > javadoc: > http://cr.openjdk.java.net/~rriggs/signal-doc/ > > Webrev: > jdk: http://cr.openjdk.java.net/~rriggs/webrev-signal-8087286/ > hotspot: http://cr.openjdk.java.net/~rriggs/webrev-hs-signal-8087286/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8087286 > > JEP 260: > https://bugs.openjdk.java.net/browse/JDK-8132928 > > Thanks, Roger > >