On Thu, 18 Mar 2021 14:30:21 GMT, Thomas Stuefe <stu...@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? > >> 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? ------------- PR: https://git.openjdk.java.net/jdk/pull/3049
