Especially as we know the forked money should *exit before* the main process, so we should be able to flush the ACK...
The timeout would just be a fallback to prevent zombies On Sun 19 Feb 2017 at 21:09, Michael Osipov <micha...@apache.org> wrote: > 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 > > -- Sent from my phone
