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

[Thomas Stüfe]

On Fri, Feb 5, 2016 at 3:00 AM, Stuart Marks <stuart.marks at oracle.com>
wrote:

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

Would that not be a case for a new JEP? Introducing an official signal
handling API feels to big to me for just a normal change. Having a JEP
would give a good forum for discussions.

That said, I can see both sides.

I am not happy with exposing a generic Signal handling API, but I feel that
I if this is really needed, we should very carefully select the signals we
allow the user to manipulate, and clearly document this list and stick to
it. Any signal in this list is a compatibility promise to the user and we
cannot use this signal for ourselves in future releases.

In my opinion we should then aim for compatibility among Posix platforms,
e.g. a java program written on Linux x86 should work seamlessly on MacOs or
on Linux with different architecture. So, we should leave out all signals
which are either not supported universally or behave differently on
different platforms.

We also should exclude all signals out the VM uses for itself or may use
for itself in the future (e.g. in the face of a new port to a new
architecture).

So, as examples, we should exclude from this list Posix realtime signals
(platform dependend and do not exist on MacOS), SIGTRAP (used on PowerPC
and Arch64 (?) by the VM), exotics like SIGDANGER or SIGCPUFAIL (aix only)
etc. Also, of course, all error signals like SIGSEGV, SIGILL etc.

Signals I think could be useful to expose would be anything needed to write
UNIX terminal applications, like SIGTTIN/SIGTTOUT or SIGTSTP.

Kind Regards, Thomas