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