RFR 9: 8087286 Need a way to handle control-C and possibly some other signals
chris.hegarty at oracle.com
Mon Feb 1 16:47:43 UTC 2016
Thank you for taking this on Roger.
An initial question to help my understanding. [ I think I need to
understand this, before I can comment further on the API ]
I'm a little confused about how the default handler is supposed to
work, so I looked at the implementation and become even more confused.
The consumer is registered on a per instance basis, and the instance
is added to the static map when it is created. So it appears that the
registered handler is not dependent on when the last register() is
called, but when the last instance of a Signal for a specific signal
is created. Is this intended?
On 01/02/16 16:02, 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
> 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
> 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