On Thu, May 16, 2019 at 05:22:53PM +0200, Oleg Nesterov wrote:
On 05/17, Aleksa Sarai wrote:
On 2019-05-16, Oleg Nesterov oleg@redhat.com wrote:
On 05/17, Aleksa Sarai wrote:
On 2019-05-16, Oleg Nesterov oleg@redhat.com wrote:
On 05/16, Christian Brauner wrote:
With the introduction of pidfds through CLONE_PIDFD it is possible to created pidfds at process creation time.
Now I am wondering why do we need CLONE_PIDFD, you can just do
pid = fork(); pidfd_open(pid);
While the race window would be exceptionally short, there is the possibility that the child will die
Yes,
and their pid will be recycled before you do pidfd_open().
No.
Unless the caller's sub-thread does wait() before pidfd_open(), of course. Or unless you do signal(SIGCHILD, SIG_IGN).
What about CLONE_PARENT?
I should have mentioned CLONE_PARENT ;)
Of course in this case the child can be reaped before pidfd_open(). But how often do you or other people use clone(CLONE_PARENT) ? not to mention you can trivially eliminate/detect this race if you really need this.
Don't get me wrong, I am not trying to say that CLONE_PIDFD is a bad idea.
But to me pidfd_open() is much more useful. Say, as a perl programmer I can easily use pidfd_open(), but not CLONE_PIDFD.
Right, but for a libc, service- or container manager CLONE_PIDFD is much nicer when spawning processes quickly. :) I think both are very good to have.
Thanks, Oleg. As always super helpful reviews. :) Christian