RFR [8023130] (process) ProcessBuilder#inheritIO does not work on Windows
Ivan Gerasimov
ivan.gerasimov at oracle.com
Sat Sep 14 18:58:32 UTC 2013
On 12.09.2013 19:21, Alan Bateman wrote:
> On 12/09/2013 06:59, Ivan Gerasimov wrote:
>> Hello Alan, Martin, everyone!
>>
>> Some update on the issue.
>> When trying to integrate my test into Basic.java, I found that it
>> already contains exactly the same.
>> I have just overlooked it before.
>>
>> Additional investigation showed that inheritIO() doesn't always fail
>> on Windows.
>> If the scenario is like following:
>> - java application creates a child java process (no IO inheritance,
>> redirecting IO through pipes by default),
>> - child process creates a grandchild which inherits the child's
>> stdin/out/err,
>> everything works as expected.
>>
>> However, if the java app (started from a console) creates an
>> immediate child that inherits its parent stdin/out/err, it fails.
>>
>> That's why this bug hasn't been caught by Basic.java before - because
>> it uses the first testing scenario.
>> And that's why I had to introduce a new shell script test - because
>> the problem couldn't be reproduced otherwise.
>>
>> Would you please review the updated webrev?
>> http://cr.openjdk.java.net/~igerasim/8023130/1/webrev/
>> <http://cr.openjdk.java.net/%7Eigerasim/8023130/1/webrev/>
>>
>>
> Based on the previous mails then the update to ProcessImpl_md.c seems
> right. It's probably best to give this one some bake time in jdk8
> before you backport it to jdk7u-dev. The reason is that the Process
> code likes to bite back when it is changed.
>
> On the tests then you probably know we don't like shell tests because
> they are usually slower and statistically more troublesome. Given the
> scenario that you are trying to test (and it's useful that you've got
> to the bottom of the issue) there they may not be other options here.
> One small concern with the shell test as it stands is that it looks
> like it is depend on the exact output. This makes me wonder about how
> it will behave with a debug or fastdebug build that might have
> additional output.
I only changed the way the test is called.
When the same test is run from Basic.java, it's also expected to receive
some certain output.
So I think that if it worked well from Basic.java, it should also work
from the shell script.
> Also a minor point but it might be more readable if the body of the
> for statement was indented.
>
Yes, done.
Would you please review the updated webrev?
http://cr.openjdk.java.net/~igerasim/8023130/2/webrev/
<http://cr.openjdk.java.net/%7Eigerasim/8023130/2/webrev/>
Sincerely yours,
Ivan
> -Alan.
More information about the core-libs-dev
mailing list