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

Paul Sandoz paul.sandoz at oracle.com
Fri Oct 18 08:14:52 UTC 2013


On Oct 17, 2013, at 9:13 PM, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:

> Thank you Alan!
> 
> Yes, I missed that fact that reading from the recycled file descriptor is actually a  problem by itself.
> 

Same here.


> 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/>
> 

That looks good: no operation on a re-cycled fd; fail-fast draining on close; and less blocking on close.

Martin makes a good point about a manual test being present is better than no test (presuming jtreg can ignore it?), which in effect could be more explicit instructions to QA :-)

If you need a proxy committer for this i can do it for you, just send me the updated webrev with the manual test.

Paul.

> Here we synchronize close() with calls to available() and read() and check for asynchronous close() that could have happened in between.
> 
> Sincerely yours,
> Ivan
> 
> 
> On 17.10.2013 16:34, Alan Bateman wrote:
>> On 15/10/2013 16:31, Ivan Gerasimov wrote:
>>> Here's the updated webrev with the solution by Paul:
>>> http://cr.openjdk.java.net/~igerasim/8024521/1/webrev/
>>> 
>>> I've also excluded the test from it.
>>> Instead, I'm going to write a manual testing instruction for SQE.
>>> 
>>> I've tested the fix and it works as expected.
>> I've looked at the updated webrev but there still appears to be an issue if the application closes the stream at just around the time that the process exits. So I think you will need to go back to a solution along the lines of the first patch so there is coordination between the process exit and the close.
>> 
>> -Alan.
>> 
>> 
> 



More information about the core-libs-dev mailing list