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 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


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