From owner-cvs-all  Sun Feb  4 15:56:28 2001
Delivered-To: cvs-all@freebsd.org
Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67])
	by hub.freebsd.org (Postfix) with ESMTP
	id E12CD37B401; Sun,  4 Feb 2001 15:56:05 -0800 (PST)
Received: (from dillon@localhost)
	by earth.backplane.com (8.11.1/8.9.3) id f14NtY316991;
	Sun, 4 Feb 2001 15:55:34 -0800 (PST)
	(envelope-from dillon)
Date: Sun, 4 Feb 2001 15:55:34 -0800 (PST)
From: Matt Dillon <dillon@earth.backplane.com>
Message-Id: <200102042355.f14NtY316991@earth.backplane.com>
To: Mikhail Teterin <mi@aldan.algebra.com>
Cc: sobomax@FreeBSD.ORG (Maxim Sobolev),
	dima@unixfreak.org (Dima Dorfman), deischen@FreeBSD.ORG,
	cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG
Subject: Re: mdconfig config file (was: cvs commit: src/sys/i386/conf GENERI C)
References:  <200102042136.f14LaqU41149@aldan.algebra.com>
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

:
:=    My rule  for using  vfork() is:  Does it  improve performance  in a
:=    noticeable way?  The answer, at  least for  mount_*, is no.  If the
:=    answer is no, you should simply use a normal fork().
:=
:=    fork() under  FreeBSD is  not all that  expensive. vfork()  will be
:=    faster, but  unless you  are fork/exec'ing a  few dozen  commands a
:=    second you will never notice the difference.
:
:I don't get  this. Why would you deliberately use  a slower method, even
:if it is only  a little bit slower? Also, someone _may_  be doing this a
:few dozen times a second -- what do we know...
:
:	-mi

    vfork() isn't quite as transparent as most people believe.  fork()
    is more portable.  Let me give you an example.


#include <stdio.h>
#include <unistd.h>

void
fubar(void)
{
    int x = 0;
    void fubar2(int);

    if (vfork() == 0) {
        execl("barf", "barf", NULL);
	_exit(0);
    }
    fubar2(++x);
}

    Fairly straightforward, right?   Well, maybe not if you turn
    optimization on:

apollo:/home/dillon> cc -c x.c -Wall
apollo:/home/dillon> cc -c x.c -Wall -O2
x.c: In function `fubar':
x.c:8: warning: variable `x' might be clobbered by `longjmp' or `vfork'

    To be absolutely correct, x should be a volatile int.  If you are
    running vfork() inside a relatively complex procedure, the variables
    that need to be volatile verses not can change from rev to rev of
    the compiler, and depend on the optimization options used.

    The most portable use of vfork() is to encapsulate it in a minimal
    procedure, and to be extremely careful with what you do inside the
    child process.  Many programs use vfork() improperly.

						-Matt



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message