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/