[comp.unix.questions] Another fork question

dlc@zog.cs.cmu.edu (Daryl Clevenger) (06/30/87)

Keywords:


Newsgroups: comp.unix.questions
Subject: Another related fork question
Organization: Carnegie Mellon University


    When I took an OS course, our text went over 4.2BSD as an example of an
implementation of an OS.  One 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.  If this is true (I don't know, is it?), then I see
the lack of copy-on-write fork implementations as the only reason for
implementing vfork().  There is no need for this ugly kludge, if fork()
were implemented correctly in the first place.  Just because the csh used
it or had a need for it is no excuse, why couldn't copy-on-write have been
used where it worked and different code on used the 750?  I know, one doesn't
want different behavior between binary compatible machines, but forking is
so common in UNIX, I really see a justification for doing copy-on-write
forks in the first place.  Of course, I am assuming that this would be as
efficient as vfork(), but if not, then maybe I am deluded.  Is my piece of
information/BSD a myth or a fact?  Did I miss something in the remainder
as far as copy-on-write vs. vfork() (besides the `shared' memory)?

						Daryl Clevenger
P.S. Guy, I agree with you 100%.

mouse@mcgill-vision.UUCP (der Mouse) (07/13/87)

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)