Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!ucbvax!cmcmanis@seismo.CSS.GOV@sun.UUCP
From: cmcmanis@seismo.CSS.GOV@sun.UUCP
Newsgroups: mod.computers.68k
Subject: Submission for mod-computers-68k
Message-ID: <8702181830.AA20074@sun.Sun.COM>
Date: Wed, 18-Feb-87 13:30:00 EST
Article-I.D.: sun.8702181830.AA20074
Posted: Wed Feb 18 13:30:00 1987
Date-Received: Thu, 19-Feb-87 20:46:04 EST
Sender: mwm@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 35
Approved: info-68k@ucbvax.berkeley.edu

Path: sun!cmcmanis
From: cmcmanis@sun.uucp (Chuck McManis)
Newsgroups: mod.computers.68k,comp.sys.amiga
Subject: Fork() under AmigaDOS and others
Keywords: fork(), shared memorry
Message-ID: <13545@sun.uucp>
Date: 18 Feb 87 18:30:00 GMT
Organization: Sun Microsystems, Inc. - Mtn View, CA
Lines: 25

With all the discussion about fork() and why you can or cannot do it
without an MMU, I thought of a solution that I haven't seen proposed
yet. 

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. 

I have not figured out if one would have to muck with such things as
duplicating the current memory allocated by the parent process, and
if so fix up such things as linked lists of data structures. 

Comments anyone? Anyone know how Lattice 3.10 does fork() ?


-- 
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.