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

[Martin Buchholz]

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>wrote:

> Hello everybody!
>
> Here's the updated webrev: http://cr.openjdk.java.net/~**
> igerasim/8024521/3/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/~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
>>
>>
>>
>