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

David Holmes david.holmes at oracle.com
Mon Feb 1 21:26:34 UTC 2016

Hi Roger,

Sorry I couldn't look into the code in extreme detail right now but 
would like to clarify the big picture ...

Can you please clarify the exact flow of control from when a signal is 
sent to the process and when the Java handler for it gets to run - what 
is handled by which thread where, and in what context (signal handling 
context or regular execution context)? I'm assuming no Java code is ever 
being executed in a signal handling context, but I'm not clear on the 
threading model being used here.

Is the VM still responsible for the initial receipt of all signals?

Howe do you manage a user-defined signal handler, for ctrl-C say, with 
the default behaviour for that signal (orderly shutdown) ?


On 2/02/2016 2: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

More information about the hotspot-runtime-dev mailing list