🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: mod.computers.68k
2 messages
2 total messages Started by bsteve Sat, 28 Feb 1987 15:53
Re: forking around
#195
Author: bsteve
Date: Sat, 28 Feb 1987 15:53
24 lines
1681 bytes
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
Re: forking around
#196
Author: m5d
Date: Mon, 02 Mar 1987 15:06
50 lines
3211 bytes
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
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads