RFR 9: 8087286 Need a way to handle control-C and possibly some other signals
Chris Hegarty
chris.hegarty at oracle.com
Tue Feb 2 16:58:30 UTC 2016
On 2 Feb 2016, at 16:35, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
:
>>>> - I agree with Peter, about the permission regarding the thread that executes
>>>> the consumer. Does it make sense to support a ThreadFactory, or may that
>>>> is overkill.
>>>>
>>>>
>>> Using InnocuousThread should be sufficient.
>>>
>> Right, but then it should be specified.
> ok
>>
>>> Adding a ThreadFactory to the register method would give more control but is probably more than necessary.
>>>
>> Hmmm… maybe. But then it is very restrictive, unless there is some mechanism
>> to override it.
>>
> same as current s.m.Signal implementation.
But, doesn’t s.m.Signal start a new thread from the VM created signal dispatcher thread
which has all permissions ( inherited ACC )? j.u.Signal will be different, it would execute
the consumer with no permissions.
:
>> So the use case is to register a handler and later restore the previously
>> set handler. It is not possible for register to return the previously registered
>> handler, and then it is up the user to store it and reset it, as necessary.
>> Rather than the default notion.
>>
> Returning the previously set handler exposes a reference to some other subsystem's object.
> In some cases it might be a security risk.
Right, but the user will have to have permission.
:
>>> if you have a Signal reference you have the power; similar to Process and ProcessHandle
>>> the security check is done to get the reference to begin with. From an auditing point of view,
>>> there is no ambiguity in code that has access to a Signal reference; if has the reference it can control
>>> the process.
>>>
>> There is a potential issue when the Signal is delivered to the consumer when it
>> is raised, if, there is any thread, other than an innocuous thread, executing the
>> consumer.
>>
>> Another small implementation question: is it still necessary for s.m.Signal.dispatch
>> to start a new Thread ?
>>
> If it re-uses the VM's Signal Dispatch thread, the latency in the signal consumer might delay other signal
> handling.
I was not suggesting that it use the VM Signal Dispatch Thread. SignalImpl.dispatch,
the common dispatch path, already starts a new thread and executes s.m.dispatch.
> Like with the Cleaner threads and functions, there is a concern about the impact of one of the clients
> on the shared resource (Thread). Starting a new thread allows the impact to be reduced.
>
> There might be an argument for using the a common executor but it might also introduce additional
> latency in processing the signal depending on the state of the executor.
> Starting a new thread has more predictable behaviour.
I was actually suggesting supporting a variant taking a thread factory, since the
API will specify that the default handler thread, created per signal raised, will
execute with no permissions.
-Chris.
> Thanks, Roger
>
>>
>> -Chris.
>>
>>
>>> (I haven't done a review with the security folks on this yet).
>>>
>>> Thanks, Roger
>>>
>>>
>>>
>>>> -Chris.
>>>>
>>>> On 1 Feb 2016, at 16:02, Roger Riggs
>>>>
>>>> <Roger.Riggs at oracle.com>
>>>>
>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>
More information about the hotspot-runtime-dev
mailing list