RFR 9: 8087286 Need a way to handle control-C and possibly some other signals
stuart.marks at oracle.com
Fri Feb 5 02:00:24 UTC 2016
On 2/4/16 5:05 PM, David Holmes wrote:
>> 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.
I agree with David on this. Providing signals to Java bytecodes for JDK-internal
use is one thing; exporting this as a public API for general use is altogether
Just because Hotspot doesn't need a signal doesn't mean that the signal should
be usable by any Java application. JDK internal users such as library code
(whether native or Java) need to handle signals for internal implementation
purposes. I see some evidence of this in Process, net, and nio. We need to make
sure that an application's use of signals doesn't interfere with the library
More information about the hotspot-runtime-dev