Joe Buck <[EMAIL PROTECTED]> writes: > 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.
vfork has been invented by Unix, it has nothing to do with porting. It was needed to avoid the overhead of copying the address space just to throw the copy away during execve. On modern systems the overhead is almost nonexistent. > 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. The only reason the parent needs to be suspended is because it shares the stack with the child. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
