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
