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

[Roger Riggs]

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.
>
> 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.

Java is used as an application programming language and environment and 
as a system programming
environment.  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.

>
> 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.

>
> 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