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
