Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!sunybcs!ugkamins
From: ugkamins@sunybcs.uucp (John Kaminski)
Newsgroups: comp.os.minix
Subject: Re: Why the 8086 architecture is wonderful :-)
Message-ID: <4566@cs.Buffalo.EDU>
Date: 7 Mar 89 22:31:31 GMT
References: <13428@ncoast.ORG> <85126@felix.UUCP>
Sender: nobody@cs.Buffalo.EDU
Reply-To: ugkamins@sunybcs.UUCP (John Kaminski)
Organization: SUNY/Buffalo Computer Science
Lines: 44

>I've never been particularly fond of fork() as a primitive operation,
>because it assumes more than is necessary about the architecture of
>the machine.  To do fork() efficently, you pretty much have to have
>a virtual memory machine.  In the "real" world, most fork() calls
>are immediately followed with an exec() call.  The copy of the
>process that fork() creates, exec() discards, so why bother making
>the copy...
>--
>Preston L. Bannister
>USENET	   :	hplabs!felix!preston
>BIX	   :	plb
>CompuServe :	71350,3505
>GEnie      :	p.bannister

It is my opinion that fork() assumes nothing about anything.  It is merely a
standard system call that has standard semantics -- i.e., you will get another
independently running process with the same program and the same variables, the
same state of just about everything...and the parent gets a pid (the returned
value).  The manual for the UNIX system in question usually clearly tells you
the semantics (in the case of MINIX, I guess that would be the description
for V7 UNIX).

Also, I agree that most of the time that exec() of some kind is usually per-
formed after most fork()s.  However, it is not always desired.  Take for
example my attempt a a real-time communications program for OS9 (which is also
supposed to mimic UNIX, at least in its system calls).  What I wished to happen
was that the program immediately split into two parts -- one for taking
keyboard input and sending it out, and another to receive characters and
display them.  Without getting OS9-specific by going on calls to see if there
was anything in the buffer (either keyboard or serial line -- and later from
another user logged on, i.e., not a terminal program), it seemed to me that
the only way to prevent the program from blocking on read() calls was to have
two independent processes, each of which could block all it wanted while
waiting for characters, because the other process would still be running or
ready to run.  A fork() as defined under UNIX would have been great, but
os9fork() requires a string argument which is the module name (executable files
are roughly the equivalent of modules) to be "exec()ed" after the new process
is created.  I had given up on the project due to lack of time, but what I was
attempting is something like os9fork(argv[0]) and have the program somehow
determine if it had already been started and if not, signal the started one
that it was the copy....as you can see, it got complicated REAL fast.

In short, if you are given the choice of fork() then exec() or forkexec(),
I'll take the control offered by separate functions any day.