On Wed, 10 Sep 2003, Christian Limpach wrote:

> Quoting Christos Zoulas <christos@zoulas.com>:
>
> > Christian Limpach <chris@pin.lu> wrote:
> > >There's still the issue of upcalls happening while the child is still
> > >running on the parent's stack.  An upcall will save the ucontext on the
> > >same stack and thus trash it.  Should we just block/hold all upcalls
> > >between vfork and when execve clears P_PPWAIT?
> >
> > It seems to me that the vfork semantics should be changed so that
> > upcalls
> > should not be happening while the child is running on the parent's
> > stack.
> > Maybe we should introduce a process flag that indicates P_INVFORK, and
> > have execve clear it. While a process is in P_INVFORK, it cannot execute
> > upcalls.
>
> yes, I have vfork set P_SA_HOLDUPCALL and execve/exit clear the flag.  If
> this flag is set, all other LWPs will sleep in sa_upcall_userret until the
> flag is cleared.  I'd prefer a SA specific flag because once we support
> multiple vp's we'll only have to block upcalls on the one vp.

vfork + pthreads is a murky area. I think we should define whatever we do
to make our lives trivial. I think we should block all upcalls, since my
understanding of the vfork() semantics is that it's supposed to support
something that will immediately exec(), with the parent stalled in the
mean time. To avoid all sorts of weirdness (like what happens on an MP
system when one thread kills a vfork()'ing thread, etc.), let's just stall
the whole process.

Take care,

Bill