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
