This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 2/3] posix: Use posix_spawn on popen
On 17/09/2018 07:50, Rich Felker wrote:
> On Sun, Sep 16, 2018 at 02:43:02PM +0930, David Newall wrote:
>> It seems to me that there are still reasonable questions about
>> whether to use posix_spawn or vfork ("posix_spawn is a badly
>> designed API"). For (well over) 30 years, I've understood that
>> vfork was the go-to call for a fork/exec scenario, so, what is the
>> technical problem with using it for popen and system? (I'm not
>> asking about vfork's overall technical merits, I'm asking
>> exclusively about using it for popen and system.)
> The historical contract of vfork is that you can basically do nothing
> after it returns in the child except for exec or _exit, and there are
> good reasons for this; sharing memory and stack with the parent has
> lots of subtle issues, especially in the presence of a non-dead-stupid
> One thing to note is that vfork is completely unsafe to use as
> documented if any signal handlers are installed, unless you block all
> signals before calling vfork, in which case the exec'd process will
> inherit a fully-blocked signal mask which is probably not what you
> want. Otherwise signal handlers may wrongly run in the child that's
> sharing memory with the parent.
> The posix_spawn implementation already takes care of these issues by
> not sharing the stack and uninstalling any signal handlers before
> unmasking signals.
And posix_spawn implementation on Linux uses the same performance
improvements that vfork aims to provide.