Hi Vineet On 11/03/13 14:31, Vineet Gupta wrote: > On Monday 11 March 2013 07:50 PM, James Hogan wrote: >> 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. > > I agree, and we are not debating the usage of vfork in Busybox - I just > mentioned > it to drive the point about semantics. FWIW, ARC port doesn't use the vfork.c > which I fixed (same as what Markos originally did). > > The point here is that we should not be changing semantics of vfork wrapper > for > legacy-syscall-abi vs. the legacy-abi one. If new vfork.c is wrong - it was > already wrong - so we might as well delete it from common code (maybe make it > arch > local if an arch exists which can reliably use the "C" version")
My point was more that implementing vfork() with fork() isn't incorrect, since according to the manpage "an implementation where the two are synonymous is compliant". Cheers James _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
