Messages in this thread | | | Date | Sun, 10 Jan 1999 02:14:00 +0100 (CET) | From | Torbjorn Lindgren <> | Subject | Re: Porting vfork() |
| |
On Fri, 8 Jan 1999 kernel@draper.net wrote: > I have checked vfork() behavior on HP-UX (B.10.20), AIX (4.2), > FreeBSD (2.2.8), and SunOS (5.5.1). Of these in only Solaris and HP-UX > does the child share memory with the calling process.
Note that SUSv2 DOES have vfork(), it's even part of the mandatory base set (as opposed to one of the feature groups)... Yikes! They do have some serious restrictions on it thought, unless you are extremely carefull you slide into undefined behavior.
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.
That's pretty stringent requirements, especially the one about *a* variable of a specific type. And if we're going to support SUSv2 it looks like we're actually better of with aliasing vfork() to fork() than providing a BSD style implementation!
(That's really weird, what on earth did they smoke when they added vfork() to SUSv2 from BSD, but removed the blocking part?)
> Both Solaris and HP-UX man pages contain strong cautions. Solaris warns > that vfork will disappear in the future and HP-UX states:
Yes, most OS'es that have vfork() seems to have lots of cautions about it in their manual pages. The closest to a BSD4.x box I could find (Ultrix 4.4) didn't have it thought, so the original BSD implementations might not have had it...
- 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/
| |