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

[Roger Riggs]

Hi Stuart,


 From your later email; all threads to invoke signal handlers are 
non-daemon threads
and are expected to return from the handler and terminate.  Yes, worth a 
spec.


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 
not available.
>
> 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 
exceptions.
>
> 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.


Thanks, Roger

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