I assume you meant ECHILD? That would definitely be a bug if there are still children present after one exits.
-Matt On Mon, Jul 10, 2017 at 8:29 AM, Imre Vadász <imrev...@gmail.com> wrote: > Ok, not related to SIGCHLD or anything like that. What I see when running > that binary, is that 2 threads are blocking in wait() and when a child > exit()s, one wait successfully returns. But the other one erronously > reports SIGCHLD instead of continuing to block as would be expected. This > definitely looks like a bug in the wait4 syscall, judging from the trace I > got with "ktrace -i ./test-nix --test-threads 4" here. > > > On Monday, July 10, 2017, Imre Vadász <imrev...@gmail.com> wrote: > >> Hi, >> Did you verify that the child isn't just exiting before the parent calls >> wait(), and getting reaped by a signal handler for SIGCHLD? This should be >> easy to verify by running the binary with ktrace. In that case getting >> ECHILD from waitpid() would be perfectly fine and could be treated as >> success. >> Regards, Imre >> >> On Monday, July 10, 2017, Michael Neumann <mneum...@ntecs.de> wrote: >> >>> >>> >>> On 07/10/17 15:40, Michael Neumann wrote: >>> > Hi, >>> > >>> > I am trying to port some Rust libraries to DragonFly, specifically the >>> > [nix] crate to access UN*X APIs from Rust. >>> >>> I think it's related to the problems that can occur when fork()ing a >>> multi-threaded program, as described here: >>> >>> http://www.linuxprogrammingblog.com/threads-and-fork-think-t >>> wice-before-using-them >>> >>> Furthermore, I think this is similar to the "cargo" issue I am seeing, >>> when running multi-threaded (it is forking and execve "rustc" and >>> probably doing something in between... sometimes it hangs). >>> >>> >>> Regards, >>> >>> Michael >>> >>
