[ On Mon, April 6, 1998 at 19:19:00 (-0000), jiho@postal.c-zone.net wrote: ]
> Subject: Re: Real vfork()  (was: third results)
>
> > I remember doing exactly the opposite and tracing through the 0.9 and
> > 1.0 sources to find out why vfork() wasn't doing as it was documented to
> > do (and as I'd always observed it to do on 4.3BSD and even SunOS-4)!  ;-)
> 
> This is something I'm scratching my head about now.
> 
> The CSRG 4.4BSD book has murky grumbling about programs exploiting the vfork()
> shared vmspace showing "bad programming practice", or some such.  That's the
> only clue I've seen.

You mean the bit in section 5.6 where they discuss that even though
vfork() is likely to remain more efficient than any copy-on-write scheme
the CSRG folks took it out and simply implemented it as fork() because
it is bad programming practice to allow a child process to modify the
parent's address space?  Yes of course some programs did do this and
naturally they broke when compiled on original 4.4BSD.

So, first people grumbled when vfork() was implemented (though not too
loudly though since before copy-on-write it was a tremendous performance
gain!), then they grumbled when they made vfork() behave ala fork()
because they'd written in dependencies on vfork() semantics, and now
some even grumble again when vfork() no longer behaves exactly as fork()
and we're forced to have a magic wrapper so only newly compiled programs
get the new/old vfork() semantics.

Unfortunately the following bug entry was removed from vfork(2) when the
"proper" semantics were implemented.

  BUGS
     This system call will be eliminated when proper system sharing mechanisms
     are implemented.  Users should not depend on the memory sharing semantics
     of vfork as it will, in that case, be made synonymous to fork.

I suppose whomever removed that paragraph will argue that there never
will be proper system sharing mechanics in NetBSD, but I wouldn't be so
quick to say that.  I will agree that it'll be unlikely for there ever
to be something faster than vfork().

Even worse the new manual page tries to tell history stories and fails
entirely to define the exact semantics of vfork().  (It also contains
what seems to be a typo: s/paged/swapping/)

The fact that someone thought that the copy-on-write semantics were
sufficiently "proper" in 4.4BSD to eliminate vfork() is quite telling.

That it has been resurrected without at minimum this BUG warning is only
asking for the same "bad programming practices" to creep back in.  That
we have to at the same time maintain binary bass-ackwards compatibility
for the old vfork() ala fork() because too many old binaries were broken
from assuming vfork() was no more than just fork() [presumably because
the child writes on global variables before the exec(), something that's
perfectly OK with fork()].

How can we ever win, let alone learn to do better?  :-) 

I know at least one suggestion, but I'll leave the reader to guess for
now!

My personal opinion is that vfork() is still an abomination and no
modern OS should support it -- copy-on-write is close enough that we
should not need to rely on stupid tricks for minor performance gain,
esp. when this teeter-totter dependence on semantics happens.  The
4.4BSD release was correct to obliterate it.  And yes I *can* say these
things -- I'm typing on a diskless Sun 3/60 with a Sparc-2 as a server,
so I know what it's like to have slow machines.

-- 
							Greg A. Woods

+1 416 443-1734      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>