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

[Chris Hegarty]

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.Riggs at 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
> 
>