Thank you Martin for the references.
I've implemented passing the limitation to the application in a similar
manner.
The timeout value is passed to the test through the CloseRaceTimeout
system property.
If the property wasn't set, the default value of 2 minutes is used.
When the application creates its child process, this value is passed
through the argument list.
In any ways this test should be run by jtreg harness, since it uses
'testlibrary' for dealing with the child process.
However, when run by hands, there's a way to specify for how long it
should work.
Sincerely yours,
Ivan
On 18.10.2013 18:50, Martin Buchholz wrote:
A precedent is my old test that does a long-running test when run in
the obvious way by hand, and a much shorter test when run by the test
harness.
* @run main RemovePollRace 12345
public class RemovePollRace {
// Suitable for benchmarking. Overriden by args[0] for testing.
int count = 1024 * 1024;
Here's another style from jsr166 that I like:
public class COWALAddIfAbsentLoops {
static final int SIZE = Integer.getInteger("size", 35000);
/**
* Set to 1 for 0% cache hit ratio (every addIfAbsent a cache miss).
* Set to 2 for 50% cache hit ratio.
*/
static final int CACHE_HIT_FACTOR =
Integer.getInteger("cache.hit.factor", 1);
static final int MAX_STRIPES = Integer.getInteger("max.stripes", 4);
static final int REPS = Integer.getInteger("reps", 3);
On Fri, Oct 18, 2013 at 4:54 AM, Ivan Gerasimov
<ivan.gerasi...@oracle.com <mailto:ivan.gerasi...@oracle.com>> wrote:
Hello everybody!
Here's the updated webrev:
http://cr.openjdk.java.net/~igerasim/8024521/3/webrev/
<http://cr.openjdk.java.net/%7Eigerasim/8024521/3/webrev/>
<http://cr.openjdk.java.net/%7Eigerasim/8024521/3/webrev/>
I put the regression test back with some slight modifications.
Now, when run in automatic mode, it uses the default time gap of 2
minutes.
This way it still has a little chance to catch a race.
Additionally I added an instruction about how to run the test with
an arbitrary timing.
Please see the comments in the test.
This should help QA make sure the race is gone.
Sincerely yours,
Ivan
On 18.10.2013 13:16, Alan Bateman wrote:
On 17/10/2013 20:13, Ivan Gerasimov wrote:
Thank you Alan!
Yes, I missed that fact that reading from the recycled
file descriptor is actually a problem by itself.
Would you please take a look at another updated webrev?
It contains another implementation suggested by Paul
Sandoz with some minor changes.
http://cr.openjdk.java.net/~igerasim/8024521/2/webrev/
<http://cr.openjdk.java.net/%7Eigerasim/8024521/2/webrev/>
<http://cr.openjdk.java.net/%7Eigerasim/8024521/2/webrev/>
Here we synchronize close() with calls to available() and
read() and check for asynchronous close() that could have
happened in between.
Thanks for the update, this looks much better. Are you
planning to update the comments in processExited, they are a
bit of out of date now.
I agree with Martin on the test. Minimally we should ensure
that we have an automated test that exercises this scenario,
even if it doesn't manage to reliably duplicate the issue with
an un-patched -JDK.
-Alan
