[lkml]   [1999]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Porting vfork()

Torbjorn Lindgren writes:
> On Fri, 8 Jan 1999 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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:49    [W:0.025 / U:0.444 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site