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