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
