Alan,
On 15/11/2011 11:26 PM, Alan Bateman wrote:
On 15/11/2011 00:56, David Holmes wrote:
:
25 * @bug 4820217 6860309
As per other emails and still waiting from confirmation from Alan. I
don't think the @bug should be updated for any of these test fixes.
The @bug tag is intended to list the
Where can we find the definition of the tag contents?
Whichever way this discussion goes, we should
update that documentation with the conclusions.
On 11/15/11 4:29 PM, David Holmes wrote:
Alan,
On 15/11/2011 11:26 PM, Alan Bateman wrote:
On 15/11/2011 00:56, David Holmes wrote:
:
25 * @bug
On 15/11/2011 21:29, David Holmes wrote:
That was somewhat non-committal :) To me @bug says these are the bugs
that this test is checking the fix for hence not applicable in any of
the recent timing/race test fixes.
It's non-committal because I don't think this has come up before, it's
looking at).
Again, the above may no longer be the current practice or recommendation.
Thanks,
iris
-Original Message-
From: Alan Bateman
Sent: Tuesday, November 15, 2011 2:37 PM
To: David Holmes
Cc: Gary Adams; core-libs-dev@openjdk.java.net
Subject: Re: CR 6860309 - solaris timing issue
- solaris timing issue on thread startup
On 15/11/2011 21:29, David Holmes wrote:
That was somewhat non-committal :) To me @bug says these are the bugs
that this test is checking the fix for hence not applicable in any of
the recent timing/race test fixes.
It's non-committal because I don't think
On 14/11/2011 00:42, David Holmes wrote:
Will the exec'd process block until the copier threads read from its
output streams? If not then the copier threads (well stdin anyway)
could read their input and have terminated before the main thread even
reaches the original sleep() call.
I don't
On 11/14/2011 05:09 PM, Gary Adams wrote:
I've updated the webrev for CR#6860309 using a CountDownLatch.
The main thread will wait til both worker threads are ready to
block on the read() before the process is destroyed.
http://cr.openjdk.java.net/~gadams/6860309/
Tested with -Xcomp, but
Updated to move static latch to Copier
constructor argument.
On 11/14/11 11:09 AM, Gary Adams wrote:
I've updated the webrev for CR#6860309 using a CountDownLatch.
The main thread will wait til both worker threads are ready to
block on the read() before the process is destroyed.
On 14/11/2011 6:05 PM, Alan Bateman wrote:
The test runs cat without any arguments so the Copier threads will block
when they read from the stream.
Thank's Alan that critical point had escaped my notice.
David
If we can get the main thread to wait
until the Copier threads are just about to
Alan,
On 12/11/2011 9:58 PM, Alan Bateman wrote:
On 11/11/2011 16:56, Gary Adams wrote:
CR 6860309 - TEST_BUG: Insufficient sleep time in
java/lang/Runtime/exec/StreamsSurviveDestroy.java
A timing problem is reported for slow solaris systems for this
test to start up a process and
On 11/11/2011 16:56, Gary Adams wrote:
CR 6860309 - TEST_BUG: Insufficient sleep time in
java/lang/Runtime/exec/StreamsSurviveDestroy.java
A timing problem is reported for slow solaris systems for this
test to start up a process and systematically torture the underlying
threads processing
On 11/12/11 6:58 AM, Alan Bateman wrote:
On 11/11/2011 16:56, Gary Adams wrote:
CR 6860309 - TEST_BUG: Insufficient sleep time in
java/lang/Runtime/exec/StreamsSurviveDestroy.java
A timing problem is reported for slow solaris systems for this
test to start up a process and systematically
Hi Gary,
On 12/11/2011 2:56 AM, Gary Adams wrote:
CR 6860309 - TEST_BUG: Insufficient sleep time in
java/lang/Runtime/exec/StreamsSurviveDestroy.java
A timing problem is reported for slow solaris systems for this
test to start up a process and systematically torture the underlying
threads
13 matches
Mail list logo
