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

[David Holmes]

Hi Roger,

On 2/02/2016 7:41 AM, Roger Riggs wrote:
> 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.

Ok. So this is primarily moving sun.misc.Signal to java.util.Signal with 
a supported API?

>>
>> Is the VM still responsible for the initial receipt of all signals?
> yes, no change.

I need to refresh myself as to how the set of acceptable signals is 
defined ie the sig masks.

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

Does that mean that a user registered ctrl-C handler will prevent the VM 
from being terminated by ctrl-C? I assume so.

I'm dubious about the need for the average user to be able to provide 
Java level "signal" handlers - it is not as clear cut as it might seem. 
These are low-level system concepts that don't really fit in to the Java 
WORA principle in my opinion. We have provided lifecycle management of 
the VM by other means, including the use of ShutdownHooks.

I guess I should have been aware of JEP 260's intentions re 
sun.misc.Signal. I don't think a public supported API is appropriate for 
this and I think it will open a can of worms when it comes to VM 
lifecycle management.

Sorry.

David
-----


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