RFR 9: 8087286 Need a way to handle control-C and possibly some other signals

[David Holmes]

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
>>> 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.
> 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:
>>
>> SIGABRT
>> SIGALRM
>> SIGBUS
>> SIGCHLD
>> SIGCONT
>> SIGEMT
>> SIGHUP
>> SIGINT
>> SIGIO
>> SIGPIPE
>> SIGPROF
>> SIGSYS
>> SIGTERM
>> SIGTRAP
>> SIGTSTP
>> SIGTTIN
>> SIGTTOU
>> SIGURG
>> SIGUSR1
>> SIGUSR2
>> SIGVTALRM
>> SIGWINCH
>> SIGXCPU
>> SIGXFSZ
>>
>> 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 
interposition library.

   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:
>>
>> SIGFPE
>> SIGILL
>> SIGKILL
>> SIGQUIT
>> SIGSEGV
>> SIGSTOP
> The first 5, I'd understand can't be handled because the VM treats them
> specially.
>
> 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.

David
-----

>>
>> 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.
>>
>> s'marks
>