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)