RFR 9: 8087286 Need a way to handle control-C and possibly some other signals
david.holmes at oracle.com
Fri Feb 5 01:05:54 UTC 2016
On 5/02/2016 4:34 AM, Roger Riggs wrote:
> Hi Stuart,
> On 2/3/2016 5:32 PM, Stuart Marks wrote:
>> 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
>>> 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
> The initial task was to provide a replacement for sun.misc.Signal.
> Sun.misc.Signal provides to Java the same set of
> signals the VM is able to handle and exposes via the JVM_findSignal,
> JVM_RegisterSignal, and JVM_RaiseSignal.
> The VM carefully handles the native state and delivers a Java safe
> notification that the signal occurred.
And sun.misc.Signal was a private internal API not intended for public
use. Simply elevating that API to full fledged public , supported, core
API is just wrong IMHO.
>> 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 concern.
It makes absolutely no sense to try and install handlers for the
majority of those signals at the Java level.
> Java is used as an application programming language and environment and
> as a system programming environment.
Please clarify that last statement. I would not, as I understand them,
classify Java as a "systems programming" language. You need to drop into
native code to do most "systems level" stuff in Java - and indeed you
can do signal management there as well using the libjsig signal
Java applications are intended to be competitive with
> other programming environments, of which
> most support handling and raising of signals. The native command
> shells, python, etc all support signals
> to control and manage applications. Each supports use of signals within
> and between applications.
> We have encouraged the use of Java for similar programming, process and
> control functions.
> Signals are a well known and used mechanism to communicate between the
> OS and applications
> and between applications. Some signal use is restricted because the
> Java runtime
> uses them (SIGSEGV, SIGFPE, SIGILL, etc.)
> of them the application is restricted from using. The others are
> handled uniformly to notify the client
> and to be able to raise them.
> Signals are a valuable communication mechanism and I don't think the
> Java runtime should
> arbitrarily restrict signal use based on an unquantified risk.
I think both parts of this are an overstatement. Java hasn't needed a
public signal handling API for the last 20 years. It's only getting one
now because modularity is forcing us to cut-off sun.misc.Signal from the
few use-cases that do need it. And we now have a "shell" mechanism that
also wants to do some process management. This is fundamentally about
ctrl-C and ctrl-\ hooks because the native shells turn those into signals.
>> In addition, the signals for which a Signal instance can be gotten via
>> Signal.of(), but which cannot be handled (throws UOE), include:
> The first 5, I'd understand can't be handled because the VM treats them
> I'll need to dig into the VM differences to see why it is the way it is.
SIGSTOP can not be caught or ignored, hence no handler allowed.
>> 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.
> Thanks, Roger
>> 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 approach.
More information about the hotspot-runtime-dev