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
