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?

@plevart, I prototyped using that technique but was concerned that it might change the test case to be different in some subtle way from the original. It adds a new subcommand to the JavaChild to add the specific behavior.
Not particularly complex but more code and dependencies to explain.

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

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