On Fri, Feb 5, 2016 at 3:00 AM, Stuart Marks <stuart.ma...@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
