On Mon, Dec 10, 2007 at 06:32:08PM -0000, Dave Korn wrote: > On 07 December 2007 20:52, Andreas Schwab wrote: > > > "Dave Korn" <[EMAIL PROTECTED]> writes: > > > >> Perhaps we could work around this case by setting environ in the parent > >> before the vfork call and restoring it afterward, but we'd need kind of > >> serialisation there, > > > > Do we? vfork should block the parent until the child calls execve or > > exit. > > I don't see anything in posix that suggests that? I'm worrying in this case > about races between multiple threads in the parent vfork'ing multiple > children, > not about the child-parent interaction, which this suggestion was a workaround > for. (But in any case, the subsequent suggestion by Ross to just fall back on > fork instead of vfork when the environment needs setting is probably the > simplest and most robust, obsoleting this earlier suggestion of mine).
While the standard's wording might need fixing, with every implementation of vfork I know of, there are no threads. It's a mechanism for systems that don't support fork (or that can only do fork in a horribly inefficient way, say because there's no MMU, and no support for copy on write), but that support the creation of new processes. It's just a cheat to support the traditional fork-followed-by-exec, an aid for porting Unix code to non-Unix systems. The reason vfork blocks the parent until the child makes a new process or quits is because that's the only supported behavior on systems that support it; it is not really "blocking the parent" at all as there is only one process. 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.
