RFR 9: 8087286 Need a way to handle control-C and possibly some other signals
Roger.Riggs at Oracle.com
Tue Feb 2 23:04:22 UTC 2016
From your later email; all threads to invoke signal handlers are
and are expected to return from the handler and terminate. Yes, worth a
On 2/2/2016 5:08 PM, Stuart Marks wrote:
> Hi Roger,
> It will be good to get this into the JDK. Lots of people have been
> asking for this.
> 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.
Remember; "as simple and small as possible"...
If you want to use a signal try it; if it throws an exception; then its
> 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?
It also says, everything is OS and implementation dependent. So no not
required; SIGHUP is not supported 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?
The default handlers are all known to shutdown; if you want to exit the
Java runtime, call exit() or shutdown.
The requirement to have a registered handler is a bit of caution to keep
the behavior more stable.
> 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.
That suggests there should be two permissions and there is a different
security context expected for handlers that throwers.
I think that makes it more complicated than necessary. In most OS,
there is no difference in the protections for throwing and catching
> 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();
yes, that would be simpler; if there is more than one Signal handler in
the process; its pretty close to undefined
about the interactions.
> 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.
Great, we're down to: of(), register(h), unregister(), name(),
number(), equals(), hashcode(), toString().
I'll take another pass at tomorrow.
> 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
>> The new java.util.Signal class provides a settable primary signal
>> handler and a
>> signal handler. The primary signal handler can be unregistered and
>> handling is
>> to the default signal handler. System initialization registers
>> default signal
>> to terminate on SIGINT, SIGHUP, and SIGTERM. Use of the Signal API
>> 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
>> 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.
>> jdk: http://cr.openjdk.java.net/~rriggs/webrev-signal-8087286/
>> hotspot: http://cr.openjdk.java.net/~rriggs/webrev-hs-signal-8087286/
>> JEP 260:
>> Thanks, Roger
More information about the core-libs-dev