Hi Vineet,
On 11/03/13 14:02, Vineet Gupta wrote:
> IMHO, the reasoning in those discussions is flawed. I agree that any "C"
> implementation of vfork is dubious - because there is no gaurantee that stack
> won't be clobbered when the vfork wrapper returns (unless arch has a
> Branch-n-link
> reg and this function simply uses that to return w/o touching the stack).
> However if the orig code vfork based "C" version existed it meant that some
> arch
> could use it. By changing it to use clone syscall with CLONE_VM |
> CLONE_VFORK |
> SIGCHLD we are simply changing the mechanism but with same semantics. Making
> it
> behave like fork is a semantical change.
>
> Note that even on MMU system - Busybox init uses vfork for certain cases to
> guarantee that parent only runs after child has exited - something which fork
> can't guarantee.
>
> And further, if an arch doesn't/can't use the common vfork.c it needs to
> define
> it's own vfork.S - but we can't make the generic definition semantically
> wrong.
Note that the vfork man page has a few relevant comments, such as this:
CONFORMING TO
4.3BSD, POSIX.1-2001. POSIX.1-2008 removes the specification of
vfork(). The requirements put on vfork() by the standards are weaker
than those put on fork(2), so an implementation where the two are
synonymous is compliant. In particular,
the programmer cannot rely on the parent remaining blocked until
the child either terminates or calls execve(2), and cannot rely on any
specific behavior with respect to shared memory.
So it sounds like busybox generically relying on vfork to block the
parent would be incorrect.
Cheers
James
_______________________________________________
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
