RFR [8024521] (process) Async close issues with Process InputStream

[Ivan Gerasimov]

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.gerasimov at oracle.com <mailto:ivan.gerasimov at 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
>
>
>
>