RFR 9: 8087286 Need a way to handle control-C and possibly some other signals
stuart.marks at oracle.com
Wed Feb 3 22:32:58 UTC 2016
On 2/2/16 7:05 PM, David Holmes wrote:
> On 3/02/2016 8:08 AM, Stuart Marks wrote:
>> It will be good to get this into the JDK. Lots of people have been
>> asking for this.
> I think this API is a big mistake. The primary usecase seems to be control-C
> interception for utilities like jshell. Adding a general purpose signal raising
> and handling mechanism to the JDK does not seem like a good solution to me.
> While you would need to use signal management under the covers I think it would
> be much cleaner to expose an API that actually captures what it is you want
> here: a mechanism to manage "interrupt" and "terminate" events at the VM level,
> in a clean cross-platform way.
OK, I've looked some at the implementation, and there's more going on here than
meets the eye.
I was under the impression (or at least I was hoping) that the API would expose
a carefully curated set of signals that are (a) known to be useful to
applications, and (b) are safe for the JVM to allow applications to handle.
Examples of this would include SIGWINCH and SIGTSTP, which are common for Unix
applications to want to handle, as well as the Control-C (SIGINT) case that
jshell among others want to handle.
But I tried out the patch and looked through the Hotspot signal handling code,
and the set of signals exposed is much broader than I would have expected. On
Mac OS X, the signals for which a handler can be registered include the following:
I'm quite surprised by this. It seems quite unwise to expose all of these.
Perhaps this is what David is concerned about. If so, I'm starting to share his
In addition, the signals for which a Signal instance can be gotten via
Signal.of(), but which cannot be handled (throws UOE), include:
It's very strange to expose Signal instances representing these signals when
they can't be handled. They can't be raised either (at least in Roger's first
patch) since raising a signal is prohibited if there's no handler installed.
I still think a signal-handling API, even a system-specific one, can be useful
for a well curated set of signals. But this implementation seems to bring an
internal interface directly out to the API. That doesn't seem like the right
More information about the core-libs-dev