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 :-(
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
