RFR 9: 8087286 Need a way to handle control-C and possibly some other signals
david.holmes at oracle.com
Mon Feb 1 21:26:34 UTC 2016
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
> 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
> The command option to reduce signal use by the runtime with -Xrs is
> 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.
> jdk: http://cr.openjdk.java.net/~rriggs/webrev-signal-8087286/
> hotspot: http://cr.openjdk.java.net/~rriggs/webrev-hs-signal-8087286/
> JEP 260:
> Thanks, Roger
More information about the core-libs-dev