On Thu, 18 Mar 2021 15:19:20 GMT, Peter Levart <plev...@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

Reply via email to