RFR 9: 8087286 Need a way to handle control-C and possibly some other signals
gerard.ziemski at oracle.com
Mon Feb 1 18:58:25 UTC 2016
I love that we are adding this Signal object. I have several questions, but please do not take them as criticism, I’m just seeking clarification and providing feedback:
#1 Re: "Consumers for signals that are unknown or reserved by the Java implementation can not be registered.”
- Why don't we want to allow unknown signals? This will make us have to update our implementation if we want to support new or platform specific signals in the future.
#2 Re: "java.util.Signal.raise()”
- That API raises the signal in the current process, but what about sending a signal to another process for interprocess communication?
#3 Re: "Signal.of("SIGINT”)”
- Is this a factory method that returns the same object if called more than once?
#4 Re: "public boolean unregister(Consumer<Signal> consumer)”
- Why is this API returning a value? Wouldn’t having a Signal API like “public Consumer<Signal> getConsumer()” be more flexible?
#5 Re: "public void registerDefault(Consumer<Signal> consumer)”
- Do we really need this API? Can’t the same be achieved with the plain vanilla “public void register(Consumer<Signal> consumer)” I guess I don’t really see what makes this API special.
> On Feb 1, 2016, at 10:02 AM, Roger Riggs <roger.riggs at oracle.com> 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.
> 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 hotspot-runtime-dev