🚀 go-pugleaf

Date: 21 Mar 87 21:24:37 GMT
To: remsit!ucla-an!cepu!ucla-cs!ucbvax!mod-computers-68k
Subject: Submission for mod-computers-68k
Responding-System: stb.UUCP

Path: stb!michael
From: michael@stb.UUCP (Michael)
Newsgroups: mod.computers.68k
Subject: Re: forking around
Message-ID: <1529@stb.UUCP>
Date: 21 Mar 87 21:24:32 GMT
References: <8702271439.AA24012@gorgo.att.com>
Reply-To: michael@stb.UUCP (Michael)
Distribution: world
Organization: STB BBS, La, Ca, USA, 90402
Lines: 28

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. 

The problem is this: 
Aside from the fact that the system does not store the file name being
executed (it could), how do you tell where the code ends and the
variables begin? What about stack references that are pointers to other
things? Return addresses? Etc?

"It'l never work". Unless you want to spend time copying the program back and
forth at each context switch.

-- 
: Michael Gersten		ihnp4!hermix!ucla-an!remsit!stb!michael
:				sdcrdcf!trwrb!ucla-an!remsit!stb!michael
: Sealed with a curse \ As sharp as a knife
: Doomed is your sole \ And dammed is your wife.