RFR [8023130] (process) ProcessBuilder#inheritIO does not work on Windows

[Ivan Gerasimov]

On 14.09.2013 22:58, Ivan Gerasimov wrote:
>
> 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.
>
Update:
Of course I tested it with JPRT, and the tests passed well on all platforms.
Though JPRT only run product versions of the tests.

Sincerely,
Ivan

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