I think this API should be a good replacement for sun.misc.Signal. Some comments:
- The second @implNote, referring to s.m.Signal, I assume can be removed? - I agree with Peter, about the permission regarding the thread that executes the consumer. Does it make sense to support a ThreadFactory, or may that is overkill. - Is it necessary for ‘raise' to declare that it may throw UOE? Since the Signal and impl are already retrieved. Or maybe there is another possibility of failure? - Signal.dispatch just calls SignalImpl.dispatch. Should the VM just do this directly? - unregister is based on the consumer, possibly lambda’s, identity ? This seems strange. - I’m still confused by the registerDefault, and I’m not sure if it is actually needed. Why can Terminator not just register as normal? - Should the instance methods that register/unregister/raise perform a security check ( in case the Signal escapes, for example in the consumer ) -Chris. On 1 Feb 2016, at 16:02, 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 > >
