Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!killer!elg
From: elg@killer.UUCP (Eric Green)
Newsgroups: comp.sys.amiga
Subject: Re: Fork -- semi-possible
Message-ID: <4219@killer.UUCP>
Date: 29 May 88 00:15:34 GMT
References: <4982@sdcsvax.UCSD.EDU>
Organization: The Unix(R) Connection, Dallas, Texas
Lines: 27

in article <4982@sdcsvax.UCSD.EDU>, hutch@net1.ucsd.edu (Jim Hutchison) says:
> Ports?  Oh my!  Yes, in the heavy duty sense you have to dup all of the
> parents resources (including program data space).  For the average use,
> things can be much simpler.
> 
> I'm porting things (junk, stuff, tidbits).  I only need to have wait() wait,
> and fork() start up a second task.  This will get me going for the
> fork()/exec() crew.  I would rather munge as little code as possible.

Hmm. Code is easy (if it's "pure", it's identical between the two processes).
For small-model Manx, static data is easy to handle (just copy it, and change
D4), and the same with stack (copy, change SP). But, things on the heap will
kill you, as will the fact that sigbits are allocated on a per-process basis
and not system-wide (meaning that all of your neatly duplicated I/O request
blocks will fail to wake you up, or else will guru you :-( ).

Thus, while it's reasonable to be able to expect multiple copies of the same
program to be runnable, it is NOT reasonable to expect the other copies to be
exact duplicates of the first, at any time in their running. Even if the OS
had resource-tracking, there is no method besides a MMU for adjusting the
pointers in linked lists upon the heap (or, at least, no cheap, easily
implemented method that would be useful on a system-wide basis).

--
    Eric Lee Green                     {cuae2,ihnp4}!killer!elg
         Snail Mail P.O. Box 92191 Lafayette, LA 70509              
"Is a dream a lie if it don't come true, or is it something worse?"