I made this proposal to Tibor too. The forked VM sends the Z, waits for
an ACK and then exits. This should be idiot proof.
Am 2017-02-19 um 22:04 schrieb Stephen Connolly:
Can we invert the sequence?
The forked process sends a Z
Then the controller sends back an ACK of some sort. If the forked process
hasn't received the ACK say 5s after sending the Z is just says screw it
and does an exit?
On Sun 19 Feb 2017 at 20:34, Christian Schulte <c...@schulte.it> wrote:
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
--
Sent from my phone
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
