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 Tue, Sep 18, 2018 at 11:00:48AM +0930, David Newall wrote:
> On 18/09/18 00:20, Rich Felker wrote:
> >The historical contract of vfork is that you can basically do nothing
> >after it returns in the child except for exec or _exit
> Yes, that is true.  My  understanding is that vfork was intended
> only as a fast way of doing fork/exec sequence.
> 
> >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.
> 
> You're saying that kernel will deliver a signal to child pid when it
> was parent pid that was signalled.  Can that really happen?

There are various conditions under which signals are delivered to an
entire process group; the most well-known is tty signals from ^C, ^\,
^Z, SIGWINCH, etc. to the tty's foreground process group. After vfork
these would be delivered to both the parent and child while they share
memory. The parent is suspended and won't act until the child execs or
exits, but mere execution of the signal handler in the child is
observably and dangerously wrong behavior.

Rich


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