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

[Stuart Marks]

A small implementation issue.

I couldn't find anything in the code or the spec about whether the thread that 
executes a handler is or isn't a daemon thread. My first inclination was to make 
sure that the handler threads are daemon threads, similar to most system-created 
threads.

But in thinking about use cases, a handler might want to do some cleanup before 
saving state and exiting. The cleanup might end up causing all non-daemon 
threads to exit, which would pull the rug out from under the handler thread 
while it's in the midst of further cleanup or saving state. That would be bad.

Thus I'm thinking that the handler threads should be non-daemon threads, and 
further that this should be specified.

What do you think?

s'marks

On 2/1/16 8:02 AM, Roger Riggs 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
>
>