Re: Would we want pidfd_open(2) & SO_PEERPIDFD?

Em ter., 25 de mar. de 2025 às 06:50, David Chisnall
<theraven@freebsd.org> escreveu:
> It would probably be good to collect the desired behaviours for process descriptors and do a proper implementation of the desired feature set.

It looks like a step into the right direction.

> Currently, process descriptors serve precisely one need: Capsicum processes can use them to wait for process termination without needing access to the global PID namespace.

I have a multithreaded application that needs to create processes that
don't call exec() after fork(). For this application, I fork() near
main() (while the process is single-threaded) and use this extra
helper child single-threaded process to do the next fork() calls. The
child uses pdfork() and passes the file descriptor to the parent. This
is not a capsicum need, and solves my problem.

I do something similar with Linux, but it's a mess (I lose the ability
to wait() on the pidfd given it's not a direct child). I wish Linux
had just copied FreeBSD's procdesc semantics. Linux pidfd is such a
mess to work with. Linux userspace isn't much better, using pidfd to
take a pid to read /proc.


-- 
Vinícius dos Santos Oliveira