Joe Buck <[EMAIL PROTECTED]> writes: > I don't think it's wise to waste time fixing theoretical bugs > exposed by close reading of the standard. Now, messing with environ > with vfork will mess up the parent process, and if that happens it's a > bug. But getting around it by using fork will harm portability, as the > only reason to bother with vfork at all is that fork might not be > available.
That's not the only reason. I used vfork because I measured performance improvements with vfork over fork. I can't remember whether I did the measurements on GNU/Linux or on NetBSD. Performance improvements are not particularly surprising. Despite the fact that, as the Open Group specification suggests, vfork is a broken interface, it was implemented to be faster than fork/exec, and it is faster. Ian
