Messages in this thread | | | Date | Mon, 11 Jan 1999 05:17:21 +0100 (CET) | From | Torbjorn Lindgren <> | Subject | Re: Porting vfork() |
| |
On Sun, 10 Jan 1999, Brandon S. Allbery KF8NH wrote: > In message <Pine.LNX.4.05.9901100143580.27606-100000@pele.fairplay.no>, > Torbjor > n Lindgren writes: > +----- > | In the description they note that some systems vfork() is the same as > | fork(), so presumably that is allowed (you just have to alias it so vfork > | exist?). And NOWHERE is there anything about suspending the original > | process, so I think a traditional vfork() implementation (like Solaris) is > | non-SUSv2-conforming anyway!?! > | > | The requirements are basically (paraphrased): > | * Don't modify any data other than a variable of type pid_t used to store > | the return value from vfork() > | * Don't return from the function in which vfork() was called. > | * Don't call any functions before successfully calling _exit(),or one of > | the exec family of functions. > +--->8 > > The restrictions are consistent with safety requirements when using a "true" > vfork(), so Solaris's implementation is valid. SUS is simply saying that
According to the Solaris man-pages (5.5.1) it suspends the calling thread until the child either calls exec*() or exits.
As I said earlier, this ISN'T in the online version of SUSv2!!! This makes ALL implementations I have heard of non-SUSv2 compliant, EXCEPT the 'alias fork to vfork' ones!
I'm not sure the version that the SUSv2 manual pages document is especially usefull, if nothing else it's FAR more dangerous if you actually implement VM sharing (for a starter I don't want to think about what could happen to the stack if you returned from the current function in the original thread BEFORE you either call exit*() or exit the program!)
The more I think of it the more I suspect that the official online SUSv2 documentation simply is wrong, EXCEPT that the description given fits the aliasing implementation perfectly...
Aliasing fork() to vfork() is beginning to sound more and more promising...
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |