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

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.