On 1 Feb 2016, at 19:10, Roger Riggs <roger.ri...@oracle.com> wrote:
> Hi Chris,
>
> On 2/1/2016 11:47 AM, Chris Hegarty wrote:
>> Thank you for taking this on Roger.
>>
>> An initial question to help my understanding. [ I think I need to
>> understand this, before I can comment further on the API ]
>>
>> I'm a little confused about how the default handler is supposed to
>> work, so I looked at the implementation and become even more confused.
>> The consumer is registered on a per instance basis, and the instance
>> is added to the static map when it is created. So it appears that the
>> registered handler is not dependent on when the last register() is
>> called, but when the last instance of a Signal for a specific signal
>> is created. Is this intended?
> The Signal instance delegates to a singleton SignalImpl instance
> (based on the name/number). I chose to delegate from Signal
> to SignalImpl to be able to put SignalImpl in a separate package that
> could be exported to the implementation of sun.misc.Signal as needed.
> Otherwise, java.util.Signal would only be able to export only its public
> interface
> and s.m.Signal needs more functions to be available.
>
> The current and default consumers are stored in the singleton SignalImpl
> objects
> that are used for the dispatch and calling of the consumer.
>
> The SignalImpl instances are create on first use. Each call to register
> re-registers the SignalImpl with the VM to ensure it will be the current
> handler.
Thanks Roger. I see this now ( glasses cleaned ;-) ). The interaction between
Signal and SignalImpl initially confused me.
Signal.of always returns a new instance of Signal. I wonder if it is worth,
somewhat,
simplify this, with the use of a SharedSecret.
Signal:
…
static {
SharedSecrets.setJavaUtilSignalAccess(
new JavaUtilSignalAccess() {
public Signal newSignal(SignalImpl impl) {
return new Signal(impl);
}
}
);
}
/** Private constructor. */
private Signal(SignalImpl impl) {
this.impl = impl;
}
public static Signal of(String name) {
Objects.requireNonNull(name, "name");
return SignalImpl.of(name).signal();
}
SignalImpl:
…
private SignalImpl(String name, int number) {
this.name = name;
this.number = number;
signal = SharedSecrets.getJavaUtilSignalAccess().newSignal(this);
}
public static SignalImpl of(String name) {
SecurityManager sm = System.getSecurityManager();
if (sm != null) {
sm.checkPermission(new RuntimePermission("handleSignal"));
}
synchronized (nameToSignal) {
// Note: Terminator initialization is too early to use lambda with
putIfAbsent
SignalImpl impl = nameToSignal.get(name);
if (impl == null) {
int number;
if (name.length() < 3 ||
(number = findSignal0(name.substring(3))) < 0) {
throw new UnsupportedOperationException("Unknown signal: " +
name);
}
impl = new SignalImpl(name, number);
nameToSignal.put(name, impl);
numberToSignal.put(impl.number, impl);
}
return impl;
}
}
public Signal signal() { return signal; }
There just seems to be some tension between these types, but maybe that is
coming,
at least somewhat, from sun.misc.Signal.
-Chris.
> Roger
>
>
>>
>> -Chris.
>>
>> On 01/02/16 16:02, Roger Riggs wrote:
>>> Please review an API addition to handle signals such as SIGINT, SIGHUP,
>>> and SIGTERM.
>>> This JEP 260 motivated alternative to sun.misc.Signal supports the use
>>> case for
>>> interactive applications that need to handle Control-C and other signals.
>>>
>>> The new java.util.Signal class provides a settable primary signal
>>> handler and a default
>>> signal handler. The primary signal handler can be unregistered and
>>> handling is restored
>>> to the default signal handler. System initialization registers default
>>> signal handlers
>>> to terminate on SIGINT, SIGHUP, and SIGTERM. Use of the Signal API
>>> requires
>>> a permission if a SecurityManager is set.
>>>
>>> The sun.misc.Signal implementation is modified to be layered on a common
>>> thread and dispatch mechanism. The VM handling of native signals is not
>>> affected.
>>> The command option to reduce signal use by the runtime with -Xrs is
>>> unmodified.
>>>
>>> The changes to hotspot are minimal to rename the hardcoded callback to
>>> the Java
>>> Signal dispatcher.
>>>
>>> Please review and comment on the API and implementation.
>>>
>>> javadoc:
>>> http://cr.openjdk.java.net/~rriggs/signal-doc/
>>>
>>> Webrev:
>>> jdk: http://cr.openjdk.java.net/~rriggs/webrev-signal-8087286/
>>> hotspot: http://cr.openjdk.java.net/~rriggs/webrev-hs-signal-8087286/
>>>
>>> Issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8087286
>>>
>>> JEP 260:
>>> https://bugs.openjdk.java.net/browse/JDK-8132928
>>>
>>> Thanks, Roger
>>>
>>>
>
