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

Rob McKenna rob.mckenna at oracle.com
Fri Oct 18 13:55:23 UTC 2013


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