I think it should be in SVN history, as Hiroki Sato changed it brieflyOn Thu, Mar 06, 2014 at 11:18:43AM +0000, David Drysdale wrote:
> On Thu, Mar 6, 2014 at 12:10 AM, Eitan Adler <lists at eitanadler.com> wrote:
> > On 5 March 2014 18:54, Jilles Tjoelker <jilles at stack.nl> wrote:
> > >
> > > Right now, waitpid(pdforked_child_pid, ...) is the only way to detect
> > > WIFSTOPPED/WIFCONTINUED and to obtain status and rusage information,
> > > since pdwait is not implemented. So I suppose it will need to be
> > > allowed.
> > This is confusing and leads to the same issues that the other
> > wait calls have. IMHO it would be better to implement pdwait() and
> > deny waitpid(). This also leads to cleaner documentation: "the wait*
> > calls do not work on process descriptors".
> > > I'm not sure about the variants of waitpid that match all child
> > > processes in a particular process group. I don't think they are commonly
> > > used.
> > >
> > >> More generally, are there any examples of pdfork() usage in practice? I
> > >> had a quick look for sandboxed things using it and didn't immediately
> > find
> > >> any...
> > >
> > > In the FreeBSD source tree, sbin/casperd and usr.sbin/rwhod use it. The
> > > former also passes the process descriptor around using libnv.
> > Yes. These are the only two consumers in the tree.
> Thanks for the pointers; I'd missed casperd as I was just looking in a 10.0
> tree -- I'll take a look.
> By the way, does rwhod actually rely on pdfork() specifically? From a
> quick glance at the code it looks like a regular fork() instead would work
> just as well.
to fork(2), but the nice property of pdfork(2) is that when parent dies,
the process descriptor of the child will be automatically closed, which
will result in kill the child. So we switched back to pdfork(2).