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

Iris Clark iris.clark at oracle.com
Tue Oct 22 19:20:32 UTC 2013


Hi, Rob.

jtreg supports identification of manual tests with the "/manual" option on various actions (see [1] and [2]).  I don't know how frequently this option is used within the JDK regression test suite.

Thanks,
iris

[1]: http://openjdk.java.net/jtreg/runtests.html
[2]: http://openjdk.java.net/jtreg/tag-spec.txt

-----Original Message-----
From: Rob McKenna 
Sent: Friday, October 18, 2013 6:55 AM
To: core-libs-dev at openjdk.java.net
Subject: Re: RFR [8024521] (process) Async close issues with Process InputStream

The question around a manual test is interesting. I've never seen a precedent for this. I think it should be relatively simple to include a manual test in the repo and make sure it doesn't get run by jtreg, (by altering the regular jtreg directives) but I wasn't aware that it was an option.

I understand it is for exceptional circumstances only, but is this worth documenting at http://openjdk.java.net/contribute/ ?

     -Rob

On 18/10/13 10: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/>
>>
>> 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




More information about the core-libs-dev mailing list