Re: fork ???

[Matthew Berg <galt gothpoodle com>]

All in all fork() is a safer bet, though it may incur a slight performance
penalty on some platforms. 

The biggest issue is that some platforms the vfork() is not universally
avaialable (BSD4.4) and on other platforms there are plans to eliminate it
in future releases (Solaris).

Also, the standard definition for vfork() is 

     (From  XPG4  / SUSv2 / POSIX draft.)  The vfork() function has the
     same effect as fork(), except that the behaviour is undefined if
     the process created by vfork() either modifies any data  other
     than a variable  of  type pid_t used to store the return value
     from vfork(), or returns from the function in which vfork() was
     called, or calls any other function before successfully calling 
     _exit() or  one  of the exec family of functions.

Taking this into account, if the fork fails, behaviour is undefined. THIS
IS BAD. :)

And finally, on several platforms vfork() is explicitely stated to be
unsafe in multithreaded applications.

As it stands, a lot of platforms have vfork() as a synonym for fork(), and
even when they are not, the cost of fork() over vfork() has been rendered
marginal due to improvements in shared memory semantics, use of demand
paging, etc.

Here are a snippets from the manpages on vfork() from all the operating
systems I have handy. :)

Linux: 

     Formally  speaking,  the  standard  description given above does
     not allow one to use vfork() since a following exec might fail, and
     then what happens is undefined.

     The  vfork() system call appeared in 3.0BSD.  In BSD 4.4 it was
     made synonymous to fork(), but NetBSD introduced it again
     cf. http://www.netbsd.org/Documentation/kernel/vfork.html .  In
     Linux, it has been  equivalent to fork() until 2.2.0-pre6 or
     so. Since 2.2.0-pre9 (on i386, somewhat later on other
     architectures) it is an independent system call. Support was added
     in glibc 2.0.112.

Solaris:

     The vfork() function is unsafe in multithreaded applications.

     This function will be eliminated in a  future  release.  The
     memory  sharing semantics of vfork() can be obtained through
     other mechanisms.

OpenBSD:

     vfork() was originally used to create new processes without fully
     copying the address space of the old process, which is horrendously
     inefficient in a paged environment.  It was useful when the purpose
     of fork(2) would have been to create a new system context for an
     execve(2).  Since fork(2) is now efficient, even in the above case,
     the need for vfork() has diminished.  vfork() differs from fork(2) 
     in that the parent is suspended until the child makes a call to 
     execve(2) or an exit (either by a call to _exit(2) or abnormally).

HP-UX:

     All HP-UX implementations must provide the entry vfork(), but it is
     permissible for them to treat it identically to fork. On some
     implementations the two are not distinguished because the fork()
     implementation is as efficient as possible. Other versions may do the
     same to avoid the overhead of supporting two similar calls.

On Sat, 15 Jul 2000, Sean Middleditch wrote:

> 
> > Oh yeah..I remember that!  I guess if your programming for Linux it
> > doesn't matter. :-)
> >
> 
> But you should try and be cross-platform anyways.  There'a good chance someone
> will want to port it, might as well make it easy on 'em to begin with.  ^,^
> 
> Sean Middleditch
> 
> 
> _______________________________________________
> gnome-devel-list mailing list
> gnome-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-devel-list
>