Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ihnp4!ptsfa!dual!ucbvax!bsteve@ucbvax.Berkeley.EDU@gorgo.UUCP
From: bsteve@ucbvax.Berkeley.EDU@gorgo.UUCP
Newsgroups: mod.computers.68k
Subject: Re: forking around
Message-ID: <8702271439.AA24012@gorgo.att.com>
Date: Sat, 28-Feb-87 10:53:55 EST
Article-I.D.: gorgo.8702271439.AA24012
Posted: Sat Feb 28 10:53:55 1987
Date-Received: Sun, 1-Mar-87 15:27:15 EST
Sender: mwm@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 24
Approved: info-68k@ucbvax.berkeley.edu

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