Hi,
I would not (did not) see this as significant but given the discussion
I'll break it down into two independent updates:
1) for JEP 260, clone the s.m.Signal Api into a JDK internal package
for use with
java.lang.Terminator and jshell with s.m.Signal layered on top
that will end up
On 08/02/2016 07:02, Stuart Marks wrote:
On 2/5/16 4:54 PM, David Holmes wrote:
Regardless of whether I agree with this API or not, it does, as
Stuart points
out, require a JEP and to go through the normal rigorous process of
determining
whether an API is suitable for inclusion in the Java
On 8 Feb 2016, at 07:02, Stuart Marks wrote:
> On 2/5/16 4:54 PM, David Holmes wrote:
>> Regardless of whether I agree with this API or not, it does, as Stuart points
>> out, require a JEP and to go through the normal rigorous process of
>> determining
>> whether an API is suitable for inclusion
On 2/5/16 4:54 PM, David Holmes wrote:
Regardless of whether I agree with this API or not, it does, as Stuart points
out, require a JEP and to go through the normal rigorous process of determining
whether an API is suitable for inclusion in the Java platform.
Note, it was Thomas Stüfe who sug
On 5/02/2016 2:24 PM, Mandy Chung wrote:
On Feb 4, 2016, at 5:05 PM, David Holmes wrote:
Java hasn't needed a public signal handling API for the last 20 years. It's only getting
one now because modularity is forcing us to cut-off sun.misc.Signal from the few
use-cases that do need it. And w
On Fri, Feb 5, 2016 at 3:00 AM, Stuart Marks
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,
>>
> On Feb 4, 2016, at 5:05 PM, David Holmes wrote:
>
> Java hasn't needed a public signal handling API for the last 20 years. It's
> only getting one now because modularity is forcing us to cut-off
> sun.misc.Signal from the few use-cases that do need it. And we now have a
> "shell" mechanism
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 n
On 5/02/2016 4:34 AM, Roger Riggs wrote:
Hi Stuart,
On 2/3/2016 5:32 PM, Stuart Marks wrote:
On 2/2/16 7:05 PM, David Holmes wrote:
On 3/02/2016 8:08 AM, Stuart Marks wrote:
It will be good to get this into the JDK. Lots of people have been
asking for this.
I think this API is a big mista
Hi Stuart,
On 2/3/2016 5:32 PM, Stuart Marks wrote:
On 2/2/16 7:05 PM, David Holmes wrote:
On 3/02/2016 8:08 AM, Stuart Marks wrote:
It will be good to get this into the JDK. Lots of people have been
asking for this.
I think this API is a big mistake. The primary usecase seems to be
contr
>
>
>
>> Which reminds me - do you propose to support the POSIX real-time signals?
>>>
>> No, I don't believe the VM supports them; it is an implementation
>> limitation.
>>
>
> Not sure what you mean here. The VM doesn't use them - which kind-of makes
> them ideal for application code use as they
On 4/02/2016 7:15 AM, Roger Riggs wrote:
Hi David,
On 2/2/2016 10:05 PM, David Holmes wrote:
On 3/02/2016 8:08 AM, Stuart Marks wrote:
Hi Roger,
It will be good to get this into the JDK. Lots of people have been
asking for this.
I think this API is a big mistake. The primary usecase seems t
Adding back hotspot-runtime-dev
On 4/02/2016 2:07 AM, Roger Riggs wrote:
Hi,
The current wording is explicit about signal support being
implementation and os dependent,
it can say its release dependent too.
So you think an API that is implementation dependent, OS dependent and
release depend
On 2/2/16 7:05 PM, David Holmes wrote:
On 3/02/2016 8:08 AM, Stuart Marks wrote:
It will be good to get this into the JDK. Lots of people have been
asking for this.
I think this API is a big mistake. The primary usecase seems to be control-C
interception for utilities like jshell. Adding a g
Hi David,
On 2/2/2016 10:05 PM, David Holmes wrote:
On 3/02/2016 8:08 AM, Stuart Marks wrote:
Hi Roger,
It will be good to get this into the JDK. Lots of people have been
asking for this.
I think this API is a big mistake. The primary usecase seems to be
control-C interception for utilities
Hi,
The current wording is explicit about signal support being
implementation and os dependent,
it can say its release dependent too.
Roger
On 2/3/2016 11:00 AM, Chris Hegarty wrote:
On 03/02/16 15:43, Thomas Stüfe wrote:
On Wed, Feb 3, 2016 at 4:20 PM, Thomas Stüfe
wrote:
On Wed, Feb
On 03/02/16 15:43, Thomas Stüfe wrote:
On Wed, Feb 3, 2016 at 4:20 PM, Thomas Stüfe
wrote:
On Wed, Feb 3, 2016 at 4:05 AM, David Holmes
wrote:
On 3/02/2016 8:08 AM, Stuart Marks wrote:
Hi Roger,
It will be good to get this into the JDK. Lots of people have been
asking for this.
I thin
On Wed, Feb 3, 2016 at 4:20 PM, Thomas Stüfe
wrote:
>
>
> On Wed, Feb 3, 2016 at 4:05 AM, David Holmes
> wrote:
>
>> On 3/02/2016 8:08 AM, Stuart Marks wrote:
>>
>>> Hi Roger,
>>>
>>> It will be good to get this into the JDK. Lots of people have been
>>> asking for this.
>>>
>>
>> I think this A
Hi Chris,
On Wed, Feb 3, 2016 at 4:22 PM, Chris Hegarty
wrote:
> On 03/02/16 15:20, Thomas Stüfe wrote:
>
>> On Wed, Feb 3, 2016 at 4:05 AM, David Holmes
>> wrote:
>>
>> On 3/02/2016 8:08 AM, Stuart Marks wrote:
>>>
>>> Hi Roger,
It will be good to get this into the JDK. Lots of peopl
On 03/02/16 15:20, Thomas Stüfe wrote:
On Wed, Feb 3, 2016 at 4:05 AM, David Holmes
wrote:
On 3/02/2016 8:08 AM, Stuart Marks wrote:
Hi Roger,
It will be good to get this into the JDK. Lots of people have been
asking for this.
I think this API is a big mistake. The primary usecase seems
On Wed, Feb 3, 2016 at 4:05 AM, David Holmes
wrote:
> On 3/02/2016 8:08 AM, Stuart Marks wrote:
>
>> Hi Roger,
>>
>> It will be good to get this into the JDK. Lots of people have been
>> asking for this.
>>
>
> I think this API is a big mistake. The primary usecase seems to be
> control-C interce
On 3/02/2016 8:08 AM, Stuart Marks wrote:
Hi Roger,
It will be good to get this into the JDK. Lots of people have been
asking for this.
I think this API is a big mistake. The primary usecase seems to be
control-C interception for utilities like jshell. Adding a general
purpose signal raising
Hi Peter,
I'll take a deeper look tomorrow, I spent some time today updating my
prototype with the suggestions.
And there is more to iterate over tomorrow.
Updated webrev:
http://cr.openjdk.java.net/~rriggs/webrev-signal-8087286/
...
On 2/2/2016 3:58 PM, Peter Levart wrote:
On 02/02/2
Hi Stuart,
From your later email; all threads to invoke signal handlers are
non-daemon threads
and are expected to return from the handler and terminate. Yes, worth a
spec.
On 2/2/2016 5:08 PM, Stuart Marks wrote:
Hi Roger,
It will be good to get this into the JDK. Lots of people have be
A small implementation issue.
I couldn't find anything in the code or the spec about whether the thread that
executes a handler is or isn't a daemon thread. My first inclination was to make
sure that the handler threads are daemon threads, similar to most system-created
threads.
But in think
Hi Roger,
It will be good to get this into the JDK. Lots of people have been asking for
this.
I have a few comments on the API.
1) Is there a way to query the set of signals supported? This might be a
Set returned by a static method, for example. I agree that signal
strings outside this set
On 02/02/2016 05:45 PM, Roger Riggs wrote:
Hi Peter,
On 2/2/2016 11:14 AM, Peter Levart wrote:
Hi Roger,
On 02/02/2016 04:16 PM, Roger Riggs wrote:
Hi Peter,
On 2/2/2016 6:44 AM, Peter Levart wrote:
...
Also if this is to become public API, There's a chance users would
want to add a
Hi Chris,
On 2/2/2016 11:58 AM, Chris Hegarty wrote:
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 implementa
On 2 Feb 2016, at 16:35, Roger Riggs 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 sufficien
Hi Peter,
On 2/2/2016 11:14 AM, Peter Levart wrote:
Hi Roger,
On 02/02/2016 04:16 PM, Roger Riggs wrote:
Hi Peter,
On 2/2/2016 6:44 AM, Peter Levart wrote:
...
Also if this is to become public API, There's a chance users would
want to add a handler to the chain of existing handlers or
Hi Chris,
On 2/2/2016 11:12 AM, Chris Hegarty wrote:
Roger,
On 2 Feb 2016, at 15:31, Roger Riggs wrote:
Hi Chris,
On 2/2/2016 8:58 AM, Chris Hegarty wrote:
I think this API should be a good replacement for sun.misc.Signal.
Some comments:
- The second @implNote, referring to s.m.Signal,
On 2 Feb 2016, at 16:14, Peter Levart wrote:
> Hi Roger,
>
> On 02/02/2016 04:16 PM, Roger Riggs wrote:
>> Hi Peter,
>>
>> On 2/2/2016 6:44 AM, Peter Levart wrote:
>>>
>> ...
>>>
>>> Also if this is to become public API, There's a chance users would want to
>>> add a handler to the chain of
Hi Roger,
On 02/02/2016 04:16 PM, Roger Riggs wrote:
Hi Peter,
On 2/2/2016 6:44 AM, Peter Levart wrote:
...
Also if this is to become public API, There's a chance users would
want to add a handler to the chain of existing handlers or override
them. So what about an API that allows regist
Roger,
On 2 Feb 2016, at 15:31, Roger Riggs wrote:
> Hi Chris,
>
> On 2/2/2016 8:58 AM, Chris Hegarty wrote:
>> I think this API should be a good replacement for sun.misc.Signal.
>>
>> Some comments:
>>
>> - The second @implNote, referring to s.m.Signal, I assume can be removed?
>>
> yes,
Hi Chris,
On 2/2/2016 8:58 AM, Chris Hegarty wrote:
I think this API should be a good replacement for sun.misc.Signal.
Some comments:
- The second @implNote, referring to s.m.Signal, I assume can be removed?
yes, except that sun.misc.Signal is still around for 9; there there
should be note
Hi Chris,
On 2/2/2016 8:44 AM, Chris Hegarty wrote:
On 1 Feb 2016, at 19:10, Roger Riggs 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 f
Hi Peter,
On 2/2/2016 6:44 AM, Peter Levart wrote:
Hi Roger,
Is this public API supposed to replace sun.misc.Signal? I don't see
why not. Comparing the APIs, thought they are different in style, I
can't find a feature of sun.misc.Signal that wouldn't be supported by
java.util.Signal except f
I think this API should be a good replacement for sun.misc.Signal.
Some comments:
- The second @implNote, referring to s.m.Signal, I assume can be removed?
- I agree with Peter, about the permission regarding the thread that executes
the consumer. Does it make sense to support a ThreadFact
On 1 Feb 2016, at 19:10, Roger Riggs 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 li
Hi Roger,
One trick to have special methods like nativeDefault() / nativeIgnore()
/ nativeRegister(long nativeHandler) (if they are needed at all) hidden
from public but be public for internal use is to:
Create a public interface in non-exported internal package, like:
package jdk.internal.m
Hi Roger,
Is this public API supposed to replace sun.misc.Signal? I don't see why
not. Comparing the APIs, thought they are different in style, I can't
find a feature of sun.misc.Signal that wouldn't be supported by
java.util.Signal except for NativeSignalHandler which in my
understanding is
Hi Roger,
On 2/02/2016 7:41 AM, Roger Riggs wrote:
HI David,
On 2/1/2016 4:26 PM, David Holmes wrote:
Hi Roger,
Sorry I couldn't look into the code in extreme detail right now but
would like to clarify the big picture ...
Can you please clarify the exact flow of control from when a signal i
HI David,
On 2/1/2016 4:26 PM, David Holmes wrote:
Hi Roger,
Sorry I couldn't look into the code in extreme detail right now but
would like to clarify the big picture ...
Can you please clarify the exact flow of control from when a signal is
sent to the process and when the Java handler fo
Hi Roger,
Sorry I couldn't look into the code in extreme detail right now but
would like to clarify the big picture ...
Can you please clarify the exact flow of control from when a signal is
sent to the process and when the Java handler for it gets to run - what
is handled by which thread wh
Hi,
On 2/1/2016 3:17 PM, Gerard Ziemski wrote:
On Feb 1, 2016, at 1:25 PM, Roger Riggs wrote:
Hi Gerard,
On 2/1/2016 1:58 PM, Gerard Ziemski wrote:
hi Roger,
I love that we are adding this Signal object. I have several questions, but
please do not take them as criticism, I’m just seeking c
> On Feb 1, 2016, at 1:25 PM, Roger Riggs wrote:
>
> Hi Gerard,
>
> On 2/1/2016 1:58 PM, Gerard Ziemski wrote:
>> hi Roger,
>>
>> I love that we are adding this Signal object. I have several questions, but
>> please do not take them as criticism, I’m just seeking clarification and
>> providi
Hi Gerard,
On 2/1/2016 1:58 PM, Gerard Ziemski wrote:
hi Roger,
I love that we are adding this Signal object. I have several questions, but
please do not take them as criticism, I’m just seeking clarification and
providing feedback:
#1 Re: "Consumers for signals that are unknown or reserved
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 lo
hi Roger,
I love that we are adding this Signal object. I have several questions, but
please do not take them as criticism, I’m just seeking clarification and
providing feedback:
#1 Re: "Consumers for signals that are unknown or reserved by the Java
implementation can not be registered.”
- W
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 confuse
50 matches
Mail list logo
