This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
> compiler.
> 
> 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.
> 
> Rich
> 

And posix_spawn implementation on Linux uses the same performance
improvements that vfork aims to provide. 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]