Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!bobkat.UUCP!m5d
From: m5d@bobkat.UUCP.UUCP
Newsgroups: mod.computers.68k
Subject: Re: forking around
Message-ID: <8703021506.AA02896@bobkat>
Date: Mon, 2-Mar-87 10:06:04 EST
Article-I.D.: bobkat.8703021506.AA02896
Posted: Mon Mar  2 10:06:04 1987
Date-Received: Thu, 5-Mar-87 19:29:57 EST
References: <8702271439.AA24012@gorgo.att.com>
Sender: mwm@ucbvax.BERKELEY.EDU
Reply-To: bobkat!m5d (Mike McNally (dlsh))
Distribution: world
Organization: Digital Lynx, Inc; Dallas, TX
Lines: 50
Approved: info-68k@ucbvax.berkeley.edu

In article <8702271439.AA24012@gorgo.att.com> bsteve@ucbvax.Berkeley.EDU@gorgo.UUCP (on Monster Island) writes:
>cmcmanis@sun.uucp (Chuck McManis) Writes:
>
>On the Amiga executables are stored in a runtime loadable format, and
>there is a system call LoadSeg() that will load the executable into
>memory and fix up all the variable references. So why can't fork()
>simply read in a new copy of the executable from disk, peek at the 
>address of it's data hunks, and copy the variables from the current
>process to the new process, duplicate the stack, and then kick it off
>with CreateProc() to make it run. You would then have two copies of 
>the code running simultaneously and not have to worry about 'swapping'
>back and forth. 
>
>> IF the desired effect is to be like the OS9 fork, this could work.
>> As for the uNIX fork()... You should get that for free with a very
>> small hack to LoadSeg() in TriPos. Just copy the existing loaded
>> image rather than reading it from disk, and then invoke CreateProc().
>> ...
>> Does this make any sense at all mike? >mike...
>
>
>    Steve Blasingame (Oklahoma City)
>    ihnp4!occrsh!gorgo!bsteve
>    bsteve@eris.berkeley.edu

What about pointers in the data space of the original process?  It is
demonstrably impossible for the OS to correctly copy and fix-up all the
pointers from the original process.  Remember, these pointers are
pointing into the original data space, not the new space.  At the very
least, this will severely confuse malloc(), which has it's own internal
pointers to keep track of free space.  As soon as the child frees
something, the parent's arena is confused.  Of course, this is just one
problem; EVERYTHING referenced by pointers is in danger.

With memory management this is not a problem.  All addresses are
virtual and are translated before actually being decoded into physical
memory locations.

Re-loading everything works find for the OS9 fork, but not for a UNIX
fork.  The simplest solution I've seen is the Minix (that's the first
context in which I saw it mentioned; probably it is much older than
that) method of swapping the parent and child between the same physical
RAM.  The idea is of course that whil a process isn't running it
doesn't care where it is.

-- 
Mike McNally, mercifully employed at Digital Lynx ---
    Where Plano Road the Mighty Flood of Forest Lane doth meet,
    And Garland fair, whose perfumed air flows soft about my feet...
uucp: {texsun,killer,infotel}!pollux!bobkat!m5d (214) 238-7474