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

David Holmes david.holmes at oracle.com
Thu Feb 4 01:03:43 UTC 2016

On 4/02/2016 7:15 AM, Roger Riggs wrote:
> Hi David,
> On 2/2/2016 10:05 PM, David Holmes wrote:
>> On 3/02/2016 8:08 AM, Stuart Marks wrote:
>>> Hi Roger,
>>> It will be good to get this into the JDK. Lots of people have been
>>> asking for this.
>> I think this API is a big mistake. The primary usecase seems to be
>> control-C interception for utilities like jshell. Adding a general
>> purpose signal raising and handling mechanism to the JDK does not seem
>> like a good solution to me. While you would need to use signal
>> management under the covers I think it would be much cleaner to expose
>> an API that actually captures what it is you want here: a mechanism to
>> manage "interrupt" and "terminate" events at the VM level, in a clean
>> cross-platform way.
>> Aside: If you want to see some prior art in this area look at
>> PosixSignalHandler API in the Real-Time Specification for Java.
> Looked at it; it provides access to Posix signals with async delivery.
> Is there some specific point of interest there?

Just an example of how signal interaction in Java has been handled in 
the past.

>> Which reminds me - do you propose to support the POSIX real-time signals?
> No, I don't believe the VM supports them; it is an implementation
> limitation.

Not sure what you mean here. The VM doesn't use them - which kind-of 
makes them ideal for application code use as they won't interfere with 
the "normal" signals which have very specific purposes and mostly are 
not intended for general use.


> Roger
>> David
>> -----
>>> I have a few comments on the API.
>>> 1) Is there a way to query the set of signals supported? This might be a
>>> Set<String> returned by a static method, for example. I agree that
>>> signal strings outside this set shouldn't be supported.
>>> 2) The Signal class spec mentions SIGINT, SIGHUP, and SIGTERM
>>> explicitly. Are these required to be implemented on all platforms, or
>>> just on "unix-like" platforms, are they just examples? What signals are
>>> available on Windows?
>>> 3) raise() is spec'd to throw an exception if there's no handler
>>> registered. But wouldn't it make sense to allow it if the default
>>> handler is registered?
>>> 4) In an earlier message you said that the Signal object is a
>>> capability, so the security check is on getting a reference. It seems to
>>> me that setting a handler is in a different category from raising a
>>> signal; this suggests to me that using the same object as a capability
>>> for both should be rethought.
>>> 5) I don't understand the asymmetry between register() and unregister().
>>> Your earlier exchanges with Chris and with Gerard touched on this,
>>> specifically, the requirement that the caller pass unregister() a
>>> reference to the old handler in order for unregistration to work. You
>>> had said this was safer, if there are uncoordinated pieces of code
>>> attempting to set/unset signal handlers.
>>> It looks to me like this API is really about maintaining process global
>>> state consisting of a single handler -- user-specified or default -- for
>>> each supported signal. (I agree that it shouldn't try to have a stack or
>>> a chain of handlers.) There are a few other things that are global like
>>> this, such as the security manager and policy, System.setIn/Out/Err, and
>>> so forth. As such, uncoordinated access to the signal API is pretty much
>>> broken no matter what. Thus I don't think it makes sense to have a
>>> CAS-like protocol for unregistering a handler, to protect against the
>>> case where "somebody else" might have registered a handler different
>>> from yours.
>>> Something like this might make sense:
>>>      void register(Consumer<Signal> handler);
>>>      void unregister();
>>> The register() call would be pretty much as currently specified; the
>>> unregister() call would restore the default handler. Alternatively,
>>> register(null) could be used instead of unregister(), but this is quite
>>> minor.
>>> Thanks,
>>> s'marks
>>> On 2/1/16 8:02 AM, Roger Riggs wrote:
>>>> Please review an API addition to handle signals such as SIGINT,
>>>> SIGHUP, and
>>>> 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