Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!whuxl!whuxlm!harpo!decvax!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.unix,net.unix-wizards
Subject: Re: Help Measuring Fork/Exec Overhead
Message-ID: <2717@sun.uucp>
Date: Wed, 28-Aug-85 02:09:07 EDT
Article-I.D.: sun.2717
Posted: Wed Aug 28 02:09:07 1985
Date-Received: Fri, 30-Aug-85 08:38:04 EDT
References: <782@druak.UUCP> <907@brl-tgr.ARPA> <2697@sun.uucp> <958@brl-tgr.ARPA>
Organization: Sun Microsystems, Inc.
Lines: 17
Xref: watmath net.unix:5491 net.unix-wizards:14608

> > ... there's not much point in copy-on-write if the
> > smallest unit that can be mapped is an entire segment).
> 
> I don't see that.  Most fork()s are almost immediately followed
> by exec(), so that avoiding the useless copying of data segments
> still seems like a big win.

You'll still copy the stack segment, as a bare minimum.  If "exec" touches
the data space in any way, you copy it too.  (Yes, there are systems where
"exec" touches the data space - the PDP-11's system call sequence didn't
involve parameters pushed onto the stack, so they had to be put into a
static area instead.  Also, if you "exec" a lot of shell files and don't
have a system whose kernel can detect that and run a shell (i.e., the
4.xBSD/V8(?) #! stuff), the first "exec" will return an error code, stored
in "errno" - blammo, time to copy the whole data segment.)

	Guy Harris