Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!husc6!linus!philabs!micomvax!musocs!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.unix.questions
Subject: Re: Another fork question
Message-ID: <841@mcgill-vision.UUCP>
Date: Mon, 13-Jul-87 01:37:43 EDT
Article-I.D.: mcgill-v.841
Posted: Mon Jul 13 01:37:43 1987
Date-Received: Tue, 21-Jul-87 03:49:43 EDT
References: <1032@zog.cs.cmu.edu>
Organization: McGill University, Montreal
Lines: 22

In article <1032@zog.cs.cmu.edu>, dlc@zog.cs.cmu.edu (Daryl Clevenger) writes:
> When I took an OS course, [...] [o]ne point that was made is that the
> reason that copy-on-write fork was not implemented in any BSD was
> beacause of a hardware bug in the VAX 11/750.

Is this really true?  I have been thinking of implementing COW fork,
but we have a 750, and so I would really like to know if any such
efforts are doomed to failure before they even start.  If it is true,
what is the bug (maybe it's possible to hack around it or something...)

> Of course, I am assuming that this would be as efficient as vfork(),

Hm.  It depends on which is more efficient - passing the virtual memory
back and forth and suspending the parent and all the other nonsense
that happens with or because of vfork, or creating copies of the
(presumably few) pages the child touches before it exec()s?  I expect
that vfork is, and COW fork would, be fast enough that the difference
(whatever it is) could be ignored.

					der Mouse

				(mouse@mcgill-vision.uucp)