Am 19.02.2017 um 21:10 schrieb Michael Osipov: > Am 2017-02-19 um 19:54 schrieb Christian Schulte: >> Am 02/19/17 um 19:52 schrieb Christian Schulte: >>> Am 02/19/17 um 19:47 schrieb Christian Schulte: >>>> Am 02/19/17 um 13:06 schrieb Michael Osipov: >>>>> Socket give you, of course, a lot of control, but they also impose an >>>>> overhead compares to named pipes (mkfifo, CreateNamePipe). >>>>> >>>>> I think our biggest problem is that stdout is subject to buffering >>>>> issues and in case if System#exit() status Z is the buffer, never >>>>> written out. >>>>> Surefire thinks that the crashed. >>>> >>>> Not sure I understand the issue at hand completely. If the code calling >>>> "exit" is in Surefire and the code consuming the stdout/stderr streams >>>> also is in Surefire, there is a solution to this. Can we just close the >>>> stdio streams before calling exit? Would that be possible? Just add >>>> System.out.close(), System.err.close() and System.in.close() before the >>>> call to System.exit(). This could solve it. Will look up posix >>>> documentation on this now. We maybe are just running into an issue where >>>> the BSDs get it right and others are not strictly posix compliant. >>>> Getting someone to test this on OSX would be interesting (kernel or >>>> userland issue). This could even be a bug in the VM (not platform >>>> independent). >>>> >>>> Regards, >>>> >>> >>> Quoting from here: >>> >>> <http://man.openbsd.org/OpenBSD-current/man3/stdio.3> >>> >>> "A file is disassociated from a stream by “closing” it. Output streams >>> are flushed (any unwritten buffer contents are transferred to the host >>> environment) before the stream is disassociated from the file." >>> >>> BUGs section has a hint about buffering as well. >>> >>> Regards, >>> >> >> Well. It's mentioned there explicitly: >> >> "If the main function returns to its original caller, or the exit(3) >> function is called, all open files are closed (hence all output streams >> are flushed) before program termination. Other methods of program >> termination may not close files properly and hence buffered output may >> be lost. In particular, _exit(2) does not flush stdio files. Neither >> does an exit due to a signal. Buffers are flushed by abort(3), as >> required by POSIX, although in previous implementations they were not." > > This is the same content as for FreeBSD and I think this is likely the > case here. BSDs strictly adhere to the standards, other implementations > like GNU/Linux might be sloppier. > > Using stderr could be a solution. At best, we would have setbuf(STDOUT, > NULL) from without Java, but this requires native code :-(
The buffering of System.in/out/err is controlled solely by the OS and the VM does not do anything to make this behave consistently across OSes? The VM isn't platform independent in that area then. If you can present a native solution on how to make the VM more platform independent in that area, time to file a bug against the JDK <https://bugs.openjdk.java.net>, IMHO. Does not solve our issue now, though. Means we need to find a solution for Surefire which is neither a hack nor a workaround which will hit us again in the future. Maybe System.in/out/err cannot be used reliably for what we are using it for. Regards, -- Christian --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
