[BusyBox] Re: [patch] Why busybox xargs is broken.

[Erik Andersen]

On Fri Oct 03, 2003 at 03:32:14PM -0500, Rob Landley wrote:
> On Friday 03 October 2003 05:23, Erik Andersen wrote:
> > On Fri Oct 03, 2003 at 01:39:12PM +0400, Vladimir N. Oleynik wrote:
> > > Erik,
> > >
> > > >>+			waitpid(p,&retval,0);
> > > >
> > > >I recommend using just wait(&retval)
> > > >
> > > >>+			return retval>>8;
> > >
> > > I do not understand, what for to change this my piece of a code.
> > > I for a long time have noticed, that many do not understand
> > > as vfork() function works and try to get rid of it. :-(
> >
> > The problem is on some Linux architectures (such as powerpc)
> > vfork does not work or is not implemented at all (for example
> > with all 2.0.x kernels).  In glibc (and in uClibc to try and
> > match glibc behavior) for these architectures, vfork() is
> > implemented with just a call to fork() and there is not even a
> > call to wait() in the fake vfork implementation...
> >
> > So unfortunately, we can not really rely on the vfork semantics
> > -- sometimes the parent process will not actually be blocked
> > until the child exits.  So adding the extra call to wait() is a
> > good idea to avoid wierd sequencing problems.
> >
> >  -Erik
> 
> Alright, would somebody please tell me what the difference between "vfork" and 
> "fork" is?  I've wondered for years. The man page on vfork doesn't give you 
> any useful information, it just repeats "use fork instead, infidel!" about 
> five hundred times and then goes on to insult vfork's ancestry.  (Really!  Go 
> read it!)
> 
> It goes out of its way to avoid giving any information about why linux 
> bothered to implement it, or why one might actually want to use it...

My manpage is quite a bit more informative.  Regardless, here is
the SuSv3 discussion on vfork -- see esp the APPLICATION USAGE

http://www.opengroup.org/onlinepubs/007904975/functions/vfork.html

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--