Re: Is anybody working on extending procdesc support to rfork?

On Wed, Jan 07, 2026 at 07:34:40PM -0700, Alan Somers wrote:
> On Wed, Jan 7, 2026 at 7:22 PM Konstantin Belousov <[email protected]> wrote:
> >
> > On Wed, Jan 07, 2026 at 08:06:59AM -0700, Alan Somers wrote:
> > > /*
> > >  * pdrfork - a procdesc-enabled version of rfork, to support pd_spawn
> > >  * fdp is return storage for the process descriptor
> > >  * pdflags are as described in pdfork(2)
> > >  * rflags are as described in rfork(2)
> > >  */
> > > int pdrfork(int *fdp, int pdflags, int rflags);
> >
> > I put together a naive (might be too naive) implementation for just that.
> > See https://reviews.freebsd.org/D54592, you are assigned as the reviewer.
> >
> > I made the operation without RFPROC flag requiring the current process.
> >
> > Would you wrote some tests to catch the expected behavior?
> 
> Wow, that was fast!  Yes, I will write some tests tomorrow.
> 
> Unfortunately, I have made another discovery.  While trying to
> implement the Rust feature today, I discovered that it isn't really
> possible to do correctly, because we don't have any race-free way to
> do wait4() on a process descriptor.  The only way to wait on a process
> descriptor is to convert it into a pid.  I didn't at first realize
> that this would be a problem, because there are multiple ways to watch
> for a process descriptor to exit (poll(), select(), and kevent()).
> However, none of those methods also reap the resulting zombie.
> There's an old bug to create a pdwait4() call
> (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235871), but it's
> had no progress for 7 years.
That's fair.  The bug report references discussion at
 https://lists.cam.ac.uk/pipermail/cl-capsicum-discuss/2015-May/msg00012.html
which seems to be no longer available.  Does anybody have a pointer
to it?