🚀 go-pugleaf

> 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. 
>>
> Steve Blasingame writes:
>>> 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().
>>
>
> Mike McNally writes:
>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.

Hardly impossible.
You have to do some dynamic relocation in order to make this work. This
means keeping some of the original linking information around. It isn't
really too much to pay.

>With memory management this is not a problem.

Yup, but lets not get into this diatribe again. And yes... we all know how
it works.

>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.

Bletch. This is another reason why this is a toy operating system. This
is fine for a system with VERY few processes, but for any more than
several it will really suck cpu on context switches.

   Steve Blasingame (Oklahoma City)
   ihnp4!occrsh!gorgo!bsteve
   bsteve@eris.berkeley.edu
   bsteve@gorgo.att.com

    Steve Blasingame (Oklahoma City)
    ihnp4!occrsh!gorgo!bsteve
    bsteve@eris.berkeley.edu