On 23/08/2012 6:37 PM, Frank Ding wrote:
Hi David,
Sorry that Jonathan has already committed the code with bug id 7193463.
Could you please dup the 2 bugs?
Alan has already taken care of it.
David
Best regards,
Frank
On 8/23/2012 4:27 PM, David Holmes wrote:
On 23/08/2012 6:05 PM, Frank Di
Hi David,
Sorry that Jonathan has already committed the code with bug id
7193463. Could you please dup the 2 bugs?
Best regards,
Frank
On 8/23/2012 4:27 PM, David Holmes wrote:
On 23/08/2012 6:05 PM, Frank Ding wrote:
Thanks all. I created sun bug 7193463 to track the code change.
We al
Changeset: e7b53fe85540
Author:dingxmin
Date: 2012-08-23 16:28 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e7b53fe85540
7193463: Improve registering signal handlers in java.lang.Terminator.setup()
Reviewed-by: dholmes, alanb
! src/solaris/classes/java/lang
On 23/08/2012 6:05 PM, Frank Ding wrote:
Thanks all. I created sun bug 7193463 to track the code change.
We already have 7189865 for this.
David
Best regards,
Frank
On 8/22/2012 10:13 AM, David Holmes wrote:
On 22/08/2012 12:11 PM, Frank Ding wrote:
Hi Alan and David,
So is it OK to commi
Thanks all. I created sun bug 7193463 to track the code change.
Best regards,
Frank
On 8/22/2012 10:13 AM, David Holmes wrote:
On 22/08/2012 12:11 PM, Frank Ding wrote:
Hi Alan and David,
So is it OK to commit the patch in Terminator class? I think Neil will
continue proposing the change in c
On 22/08/2012 12:11 PM, Frank Ding wrote:
Hi Alan and David,
So is it OK to commit the patch in Terminator class? I think Neil will
continue proposing the change in cvmi mailing list.
As Alan already said:
"Both David and I have already reviewed Frank's change and okay with it."
Cheers,
David
Hi Alan and David,
So is it OK to commit the patch in Terminator class? I think Neil
will continue proposing the change in cvmi mailing list.
Many thanks to all.
Best regards,
Frank
On 8/17/2012 4:58 PM, Alan Bateman wrote:
On 16/08/2012 16:32, Neil Richards wrote:
:
However, I still c
On 16/08/2012 16:32, Neil Richards wrote:
:
First, I think the discussion on the particular VM implementation
behaviour is a slight diversion from Frank's suggested change, which I
believe is all about making the Java code more robust / agnostic to the
VM implementation behaviour.
I think it was
On Thu, 2012-08-09 at 09:54 +0100, Alan Bateman wrote:
> On 08/08/2012 17:10, Neil Richards wrote:
> > :
> > Hi Alan,
> > Apologies, I confused myself about the Hotspot behaviour.
> > (I was testing with 'nohup', but not checking the contents of
> > 'nohup.out' for the output from my registered shu
On 08/08/2012 17:10, Neil Richards wrote:
:
Hi Alan,
Apologies, I confused myself about the Hotspot behaviour.
(I was testing with 'nohup', but not checking the contents of
'nohup.out' for the output from my registered shutdown hook - doh!).
You're correct, when running with Hotspot with 'nohup'
Thanks Neil for clarifying it in such a convincing way.
And David for creating CR.
So now we're ready to commit this patch?
Best regards,
Frank
On 8/8/2012 8:57 AM, David Holmes wrote:
On 8/08/2012 4:07 AM, Neil Richards wrote:
On Tue, 2012-08-07 at 18:01 +0100, Alan Bateman wrote:
On 07/08/2
On Wed, 2012-08-08 at 13:28 +0100, Alan Bateman wrote:
> On 07/08/2012 19:07, Neil Richards wrote:
> > :
> > Digging back into its history, I see that it all stems from running java
> > under 'nohup' (e.g. 'nohup java ProgramWithShutdownHooks&').
> >
> > 'nohup' prevents things being registered aga
On 07/08/2012 19:07, Neil Richards wrote:
:
Digging back into its history, I see that it all stems from running java
under 'nohup' (e.g. 'nohup java ProgramWithShutdownHooks&').
'nohup' prevents things being registered against SIGHUP, so trying to do
so causes an exception to be thrown.
When th
On 8/08/2012 4:07 AM, Neil Richards wrote:
On Tue, 2012-08-07 at 18:01 +0100, Alan Bateman wrote:
On 07/08/2012 15:02, Neil Richards wrote:
:
From a Java Class Library point of view, it seems to me that the desire
is to register shutdown hooks for any of these signals (HUP, INT and
TERM) who
On Tue, 2012-08-07 at 18:01 +0100, Alan Bateman wrote:
> On 07/08/2012 15:02, Neil Richards wrote:
> > :
> > > From a Java Class Library point of view, it seems to me that the desire
> > is to register shutdown hooks for any of these signals (HUP, INT and
> > TERM) whose use has not been restricted
On 07/08/2012 15:02, Neil Richards wrote:
:
> From a Java Class Library point of view, it seems to me that the desire
is to register shutdown hooks for any of these signals (HUP, INT and
TERM) whose use has not been restricted by the VM.
So an attempt to register for each of these signals should
On Tue, 2012-08-07 at 10:15 +0100, Alan Bateman wrote:
> On 07/08/2012 04:35, David Holmes wrote:
> >
> > The change is harmless but as far as I can see you would have to
> > customize the VM before this change would have any affect. The signals
> > involved here are the SHUTDOWNn_SIGNAL values (
On 07/08/2012 04:35, David Holmes wrote:
The change is harmless but as far as I can see you would have to
customize the VM before this change would have any affect. The signals
involved here are the SHUTDOWNn_SIGNAL values (which for linux/solaris
are HUP, INT and TERM). JVM_RegisterSignal si
On 7/08/2012 1:03 PM, Frank Ding wrote:
Hi Holmes,
David :)
It is not only when -Xrs is specified. The circumstances can be
illustrated below
1. a JVM has its own extra signal registration that occupies say, "INT",
prior to the execution Terminator.setup().
2. User customizes HotSpot to have
Hi Holmes,
It is not only when -Xrs is specified. The circumstances can be
illustrated below
1. a JVM has its own extra signal registration that occupies say, "INT",
prior to the execution Terminator.setup().
2. User customizes HotSpot to have similar overridden signal handling.
In both ca
On 6/08/2012 6:57 PM, Frank Ding wrote:
Hi Holmes,
I agree with your comment on duplicated comment. It should be factored out.
The context of the change is that the group of signal handlers should be
registered at best effort, which means for all JVM, we should try to
register them all in an inde
Hi Holmes,
I agree with your comment on duplicated comment. It should be
factored out.
The context of the change is that the group of signal handlers should
be registered at best effort, which means for all JVM, we should try to
register them all in an independent way. In fact, the origin
Hi Frank,
On 3/08/2012 5:39 PM, Frank Ding wrote:
Hi guys,
I found that in java.lang.Terminator, setup() method,
The following code of registering default signal handlers can be improved:
/ try {
Signal.handle(new Signal("INT"), sh);
Signal.handle(new Signal("TERM"), sh);
} catch (IllegalArgumen
Hi guys,
I found that in java.lang.Terminator, setup() method,
The following code of registering default signal handlers can be improved:
/try {
Signal.handle(new Signal("INT"), sh);
Signal.handle(new Signal("TERM"), sh);
} catch (IllegalArgumentException
24 matches
Mail list logo
