Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!pasteur!ames!oliveb!felix!preston
From: preston@felix.UUCP (Preston Bannister)
Newsgroups: comp.os.minix
Subject: Re: Why the 8086 architecture is wonderful :-)
Message-ID: <88236@felix.UUCP>
Date: 20 Mar 89 23:24:15 GMT
References: <1989Mar16.184945.23152@utzoo.uucp>
Sender: daemon@felix.UUCP
Lines: 36

From article <1989Mar16.184945.23152@utzoo.uucp>, by henry@utzoo.uucp (Henry Spencer):
> In article <1845@basser.oz> steve@basser.oz (Stephen Russell) writes:
>>... fork() is difficult/expensive to perform without
>>appropriate MMU hardware...
> 
> The Atari ST has no MMU, and Minix runs fine on it.  fork() is not as
> cheap as it would be with an MMU, but the cost is manageable.

Er, Henry are you saying that fork() without an MMU is NOT hundreds
or thousands of times as expensive as with an MMU? :-) :-)

"Cheap" is relative.

If you are forking the shell to exec() a program in response to user
typed command making a copy of the shell's address space as part of
the fork() is no big deal.  Forking GNU Emacs (or some other large
program) to exec() _is_ likely to be painful.  

The previous poster's example of communications program that uses
fork() to generate a clone of itself is _enormously_ inefficent if
the child and parent have to be swapped around in memory of each
process switch.

BTW, my objection to fork() is not just esthetic.  In daily
development I use a symbolic debugger.  The process size of the
debugger with all symbols loaded can easily get up to a megabyte.
Since we don't have copy-on-write, running (fork() and exec()) a
program from within the debugger is at best slow.  When memory is
low it can be fatal (we have a version 7 variant, i.e. swapping, no
paging).
--
Preston L. Bannister
USENET	   :	hplabs!felix!preston
BIX	   :	plb
CompuServe :	71350,3505
GEnie      :	p.bannister