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

Thomas Stüfe thomas.stuefe at gmail.com
Thu Feb 4 07:16:46 UTC 2016

>> 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.
Note that this is also platform dependend, e.g. Mac OS does not support
them. Even for platforms which support them, the semantics differ from
platform to platform, see e.g. http://zinascii.com/2014/crossed-signals.html

.. Thomas

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

More information about the hotspot-runtime-dev mailing list