HI David,
On 2/1/2016 4:26 PM, David Holmes wrote:
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.
The VM signal handling control flows are unchanged, I understand it
roughly as the vm has a native signal handler
that atomically sets an entry in an array indexed by signal number.
See os.cpp.
A separate dedicated thread waits to be woken up (signal_wait) and polls
the array (os_linux.cpp:check_pending_signals).
It then does an upcall on the dedicated thread to call the
java.util.Signal.dispatch method.
The java code takes it from there to find a registered java signal
handler and then start
a new thread to call the signal handler.
The invocation of the java handler method is asynchronous to the native
signal handler
and due to thread scheduling for the dedicated thread and the spawning
of a new thread,
quite some time may pass before the registered java signal handler is
invoked.
Is the VM still responsible for the initial receipt of all signals?
yes, no change.
How do you manage a user-defined signal handler, for ctrl-C say, with
the default behaviour for that signal (orderly shutdown) ?
System initialization registers a default signal handler for SIGINT,
SIGTERM, and SIGHUP (not windows).
If there is no registered signal handler, the default handler is invoked
in the same manner.
Roger
Thanks,
David
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
