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

[Roger Riggs]

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
>>
>>