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@xxxxxxxxxx> wrote: > > > On 05/17, Aleksa Sarai wrote: > > > > On 2019-05-16, Oleg Nesterov <oleg@xxxxxxxxxx> 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
