Messages in this thread | | | Date | Sun, 10 Jan 1999 22:16:26 -0500 (EST) | From | "Albert D. Cahalan" <> | Subject | Re: Porting vfork() |
| |
Torbjorn Lindgren writes: > 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.
Ultrix 4.3A and NetBSD both have a proper vfork(). That makes 4, plus Linux 2.2.0-pre6 now.
> 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!?!
That could be considered a process scheduling issue. Process scheduling order and time slice frequency are not well defined.
Even if not perfect, the new vfork() is closer to tradition than fork(). We might not have the details right (SIGKILL, SIGTTIN, etc.) but at least the new vfork() is more reasonable.
- 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/
| |