RFR: 8263729: [test] Extend time to wait before destroying child in ProcssBuilder Basic test

[Roger Riggs]

On Thu, 18 Mar 2021 15:19:20 GMT, Peter Levart <plevart at openjdk.org> wrote:

>>> The test expects there to be zero output from the child (and it doesn't matter what state the child is in).
>>> Can the logging from the VM be disabled or re-directed?
>> 
>> Not to the extend that it would be guaranteed never to happen. Even if we control all output in the hotspot, there are other libraries. E.g. glibc writes a lengthy report to stderr in case of a heap corruption, which I believe does not result in a hs-err file.
>> 
>> One simple solution, simpler than using two threads, could be to use ProcessBuilder::redirectError(Redirect.INHERIT) if reading stdout resp. ProcessBuilder::redirectOutput(Redirect.INHERIT) if reading stderr. One line, takes care of the stream you don't read does not block, and, we can see the child output in the parent stdout/err.
>
>> That complicates the test and the child quite a bit for minimal gain.
> 
> Suppose that the child process writes 1 byte to STDOUT and 1 byte to STDERR. In the monitoring thread in the parent process, you could read 1 byte from either STDOUT or STDERR, then count-down the latch and then block in next read. The main thread could then just wait for the latch, wait for the monitoring thread to re-enter the synchronized read method and then destroy the process... It doesn't sound too complicated. WDYT?

Redirecting the stream not being tested to INHERIT may be useful.
But the failing case is when the vm output is being directed to the stream being tested.
The command line arguments are:
    Arrays.asList(javaExe,
        "-XX:+DisplayVMOutputToStderr",
        "-classpath", absolutifyPath(classpath),
        "Basic$JavaChild");```
A combination of redirecting to inherited and sending the VM output to the same (untested) stream seems like a good option.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3049