Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!haven!decuac!felix!preston
From: preston@felix.UUCP (Preston Bannister)
Newsgroups: comp.os.minix
Subject: fork() considered harmful (was: Why the 8086 architecture is wonderful :-)
Message-ID: <86358@felix.UUCP>
Date: 10 Mar 89 03:32:13 GMT
References: <4566@cs.Buffalo.EDU>
Sender: daemon@felix.UUCP
Lines: 71

From article <4566@cs.Buffalo.EDU>, by ugkamins@sunybcs.uucp (John Kaminski):
> 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).

Ah, yes but the "standard semantics" make assumptions about what the
machine can do.  It is somewhere between difficult and impossible to
implement fork() efficiently on a "real" memory processor.

> 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 ...[deleted]
> ... 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.

Oh good! :-)

This is an example of where what you really want is something that
does _less_ than fork().  What you want for this problem is separate
processes _without_ separate address spaces.  The buzzwords are
"lightweight processes", or Mach OS "threads".  Your real-time
communications program can be most efficient if the processes
_share_ the same data.  Your subprocesses that will spend most of
their time blocked waiting for I/O probably don't need a _copy_ of
all the program's data.

> 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.

OS-9 runs on processors (6809, 68000, others?) for which Unix-style
fork() cannot be efficiently implemented, which I'm sure is why the
os9fork() call is different.

I suspect that OS-9 has a call for starting a subprocess that looks
something like:

	start_process(proc,stacksize)

Where proc is the address of a function, and stacksize is the number
of bytes to allocate for the process's stack.  (Can someone who
knows OS-9 verify this?)  You will find this both easier and more
efficient for your purposes.

> 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.

I'm not arguing against separate functions, just against the
semantics of fork().
--
Preston L. Bannister
USENET	   :	hplabs!felix!preston
BIX	   :	plb
CompuServe :	71350,3505
GEnie      :	p.bannister