This message is only the reviewers having friendly discussion with each
other!
On Mon, Jul 11, 2016 at 11:44 PM, David Holmes
wrote:
> private static final AtomicReference firstThrowable
>> = new AtomicReference<>();
>> private static final AtomicReference secondThrowable
>>
This looks fine to me.
Thanks,
David
On 12/07/2016 5:11 PM, Amy Lu wrote:
Updated on the busy-loops, also removed the unnecessary statics, here
comes the updated webrev:
http://cr.openjdk.java.net/~amlu/8132548/webrev.04/
Thanks,
Amy
On 7/12/16 2:33 PM, David Holmes wrote:
Hi Amy,
On 12/07
On 7/12/16 2:17 PM, Martin Buchholz wrote:
Amy, sorry you have so many picky reviewers!
My lucky ;-)
Additional checking for ThreadDeath may good, but with the thinking that
both group.stop() and thread.stop() are deprecated (since 1.2), I don't
want to introduce new testcase, but focus on "f
Updated on the busy-loops, also removed the unnecessary statics, here
comes the updated webrev:
http://cr.openjdk.java.net/~amlu/8132548/webrev.04/
Thanks,
Amy
On 7/12/16 2:33 PM, David Holmes wrote:
Hi Amy,
On 12/07/2016 3:28 PM, Amy Lu wrote:
Please help to review the updated webrev, gett
On 12/07/2016 4:17 PM, Martin Buchholz wrote:
Amy, sorry you have so many picky reviewers!
Difference between patching a failing test and completely redesigning it
from scratch. The latter was not warranted in my opinion.
Here's how I might write it:
import java.util.concurrent.CountDownLa
Hi Amy,
On 12/07/2016 3:28 PM, Amy Lu wrote:
Please help to review the updated webrev, getting rid of ThreadDeath and
using join():
http://cr.openjdk.java.net/~amlu/8132548/webrev.03/
I still think a simple change to the original code suffices, but given
you have gone this far ...
Busy-loo
And then somehow the unnecessary statics started to bother me:
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.atomic.AtomicReference;
public class Stop {
public static void main(String[] args) throws Exception {
final CountDownLatch ready = new CountDownLatch
Amy, sorry you have so many picky reviewers!
Here's how I might write it:
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.atomic.AtomicReference;
public class Stop {
private static final CountDownLatch ready = new CountDownLatch(1);
private static final ThreadGrou
Please help to review the updated webrev, getting rid of ThreadDeath and
using join():
http://cr.openjdk.java.net/~amlu/8132548/webrev.03/
Thanks,
Amy
On 7/11/16 6:55 PM, David Holmes wrote:
On 11/07/2016 6:14 PM, Amy Lu wrote:
Thank you David, though the email crossed-by, I hope all the c
On 11/07/2016 6:14 PM, Amy Lu wrote:
Thank you David, though the email crossed-by, I hope all the concerns
have been resolved in the updated webrev:
http://cr.openjdk.java.net/~amlu/8132548/webrev.02/
Sorry but no, the changes are neither necessary nor sufficient. With the
new code the Threa
On 7/11/16 4:14 PM, Amy Lu wrote:
Thank you David, though the email crossed-by, I hope all the concerns
have been resolved in the updated webrev:
http://cr.openjdk.java.net/~amlu/8132548/webrev.02/
I had rewrote the test with CountDownLatch and join(long millis). Also
unlike the old version, t
Thank you David, though the email crossed-by, I hope all the concerns
have been resolved in the updated webrev:
http://cr.openjdk.java.net/~amlu/8132548/webrev.02/
I had rewrote the test with CountDownLatch and join(long millis). Also
unlike the old version, test thread 'first' and 'second' do
Simplification ...
On 11/07/2016 5:12 PM, David Holmes wrote:
Hi Amy,
Thanks for tackling this.
On 8/07/2016 4:01 PM, Amy Lu wrote:
Thank you Joe for your review.
The intent is to give it more chance "for the thread group stop to be
issued", not to extend the whole test execution timeout.
I
My last email crossed with yours. Please see it.
David
On 11/07/2016 5:20 PM, Amy Lu wrote:
Please review the updated webrev:
http://cr.openjdk.java.net/~amlu/8132548/webrev.02/
Thanks,
Amy
On 7/11/16 9:20 AM, Amy Lu wrote:
Thank you for all the valuable comments.
I'm updating the webrev...
Please review the updated webrev:
http://cr.openjdk.java.net/~amlu/8132548/webrev.02/
Thanks,
Amy
On 7/11/16 9:20 AM, Amy Lu wrote:
Thank you for all the valuable comments.
I'm updating the webrev...
Thanks,
Amy
On 7/9/16 1:34 AM, Martin Buchholz wrote:
jdk/test/java/util/concurrent/tck has
Hi Amy,
Thanks for tackling this.
On 8/07/2016 4:01 PM, Amy Lu wrote:
Thank you Joe for your review.
The intent is to give it more chance "for the thread group stop to be
issued", not to extend the whole test execution timeout.
I updated the webrev to make this in a retry, limit to 5 times of
Thank you for all the valuable comments.
I'm updating the webrev...
Thanks,
Amy
On 7/9/16 1:34 AM, Martin Buchholz wrote:
jdk/test/java/util/concurrent/tck has thousands of test methods. It
used to take minutes to run them all, but now only takes 10 seconds,
mostly due to replacements of sle
jdk/test/java/util/concurrent/tck has thousands of test methods. It used
to take minutes to run them all, but now only takes 10 seconds, mostly due
to replacements of sleeps with faster and more robust alternatives, often
CountDownLatch.
On Fri, Jul 8, 2016 at 10:17 AM, joe darcy wrote:
> The m
The most surefire way to make sure the test doesn't fail anymore is to
hg rm the test; if and unless the code is actually removed, that would
not be the most appropriate approach though ;-)
While it might be overkill for this particular test, I think it would be
preferable to start replacing o
Yes, but I just thought that for a test that testing a deprecated (since
1.2) API, and failed with very very low frequency (actually, only one
time during the years), we might not want to spend much effort on a big
change, like rewrite with CountDownLatch :-)
Thanks,
Amy
On 7/8/16 2:36 PM, M
CountDownLatch is a better way of waiting for events, like for the two
threads to be started and for Thread.stop to have been called.
The test should ensure that ThreadDeath is indeed thrown. If the threads
in the group notify the main thread via a latch when they catch
ThreadDeath, then all the
Thank you Joe for your review.
The intent is to give it more chance "for the thread group stop to be
issued", not to extend the whole test execution timeout.
I updated the webrev to make this in a retry, limit to 5 times of retry:
http://cr.openjdk.java.net/~amlu/8132548/webrev.01/
Thanks,
Am
Hi Amy,
I'm a bit uncomfortable with the fix as-is.
Rather than hard-coding sleep values, if sleep values are needed I think
it is a better practice to use ones that are scaled with the jtreg
timeout factors, etc. used to run the tests. Please instead use
something like the adjustTimeout meth
Please review this trivial fix for test:java/lang/ThreadGroup/Stop.java
Though this is a test for a deprecated API, failed with very very low
frequency and hard to reproduce (I got no luck to reproduce it), I’d
like to patch it as suggested: extend the sleep in the main thread from
one second
24 matches
Mail list logo
