On 04/02/12 08:46, Chris Hegarty wrote:
I think you are both right -- the main thread must delay but need not
re-interrupt.
Yes, re-interrupting is not ideal, but it looks like
Phaser.awaitAdvanceInterruptibly differs from say CyclicBarrier.await.
CyclicBarrier.await is spec'ed to throw IE is
On 02/04/2012 13:15, Doug Lea wrote:
On 04/02/12 07:28, David Holmes wrote:
On 30/03/2012 9:22 PM, Chris Hegarty wrote:
Sorry guys, I think I found the actual cause for this failure. Though I
think the increased defensive timeouts are still a good idea.
There is a race in the test itself. The
On 04/02/12 07:28, David Holmes wrote:
On 30/03/2012 9:22 PM, Chris Hegarty wrote:
Sorry guys, I think I found the actual cause for this failure. Though I
think the increased defensive timeouts are still a good idea.
There is a race in the test itself. The "One thread interrupted" test
tries to
On 30/03/2012 9:22 PM, Chris Hegarty wrote:
Sorry guys, I think I found the actual cause for this failure. Though I
think the increased defensive timeouts are still a good idea.
There is a race in the test itself. The "One thread interrupted" test
tries to interrupt a thread blocked in awaitAdva
Sorry guys, I think I found the actual cause for this failure. Though I
think the increased defensive timeouts are still a good idea.
There is a race in the test itself. The "One thread interrupted" test
tries to interrupt a thread blocked in awaitAdvanceInterruptibly, but
how do we know the t
On Mar 27, 2012, at 2:26 AM, Alan Bateman wrote:
> On 27/03/2012 05:21, David Holmes wrote:
>>
>> It's a little disconcerting that 10 seconds is not enough time, but we have
>> so many timing issues these days it is not that surprising. :(
> The machines in question are relatively beefy but the
On 27/03/2012 11:58, Doug Lea wrote:
On 03/26/12 23:04, Chris Hegarty wrote:
.
OK. I synced with our version. As always, it is too bad that there is no
way to operationalize the notion of "for some timeout value appropriate
for the platform, no TimeoutExceptions occur".
Thanks for pushing t
On 27/03/2012 10:26, Alan Bateman wrote:
On 27/03/2012 05:21, David Holmes wrote:
It's a little disconcerting that 10 seconds is not enough time, but we
have so many timing issues these days it is not that surprising. :(
The machines in question are relatively beefy but there is hardware
visua
On 03/26/12 23:04, Chris Hegarty wrote:
David, Doug,
This test has been failing intermittently on jdk7u-dev and jdk8 for a while now.
It only appears to fail when run in our internal build/test system (JPRT).
I believe the cause of the failure to be simply that the machines the test is
run on a
On 27/03/2012 05:21, David Holmes wrote:
It's a little disconcerting that 10 seconds is not enough time, but we
have so many timing issues these days it is not that surprising. :(
The machines in question are relatively beefy but there is hardware
visualization in the picture that may be an is
On 27/03/12 05:21, David Holmes wrote:
Hi Chris,
On 27/03/2012 1:04 PM, Chris Hegarty wrote:
David, Doug,
This test has been failing intermittently on jdk7u-dev and jdk8 for a
while now. It only appears to fail when run in our internal build/test
system (JPRT).
I believe the cause of the fail
Hi Chris,
On 27/03/2012 1:04 PM, Chris Hegarty wrote:
David, Doug,
This test has been failing intermittently on jdk7u-dev and jdk8 for a
while now. It only appears to fail when run in our internal build/test
system (JPRT).
I believe the cause of the failure to be simply that the machines the
t
David, Doug,
This test has been failing intermittently on jdk7u-dev and jdk8 for a
while now. It only appears to fail when run in our internal build/test
system (JPRT).
I believe the cause of the failure to be simply that the machines the
test is run on are too slow, or very busy, and the de
13 matches
Mail list logo
