Date: Fri, 09 Oct 2009 10:43:16 +0200 From: "Matthias Andree" <matthias.andree@gmx.de> To: "Stephen Hocking" <stephen.hocking@gmail.com> Cc: ports@freebsd.org Subject: Re: sigwait - differences between Linux & FreeBSD Message-ID: <op.u1iyiera1e62zd@balu.cs.uni-paderborn.de> In-Reply-To: <6300771b0910081838y6925627cubdbc4d4dbbc376b8@mail.gmail.com> References: <6300771b0910071753s6580c099i8c348824a6fe1a72@mail.gmail.com> <4ACDCF28.6040807@gmx.de> <6300771b0910081838y6925627cubdbc4d4dbbc376b8@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 09.10.2009, 03:38 Uhr, schrieb Stephen Hocking <stephen.hocking@gmail.com>: > It appears as if the documentation does not match up with the reality > in Linux's case. That's what the empirical evidence suggests anyway. > The code does does a waitpid after receiving the SIGCHLD to determine > what child process has exited and then searches its list of sessions > looking for that particular pid, so as to tidy up. My reception is: if the process wants SIGCHLD, it will have to install its own handler, because the default disposition for this signal is SIG_IGN (= discard signal and do not turn child process into a zombie). So use your patch for FreeBSD, feed it to the upstream maintainer with a copy of this thread and relevant quotes from the standard and manpage and move on. :) The alternative is to do away with SIGCHLD and use waitpid((pid_t)-1, WNOHANG) to poll for children that have exited. > I can to some degree understand that implementation of sigwait, as if > you state your intention to wait for a particular signal, that means > that you don't wish to ignore it. That's outside the standard. If it works on a particular Linux kernel version that doesn't mean it will work on every other. Why lose yourself in empirical programming if there are standards? -- Matthias Andree
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.u1iyiera1e62zd>