Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!labrea!decwrl!sun!imagen!atari!apratt
From: apratt@atari.UUCP
Newsgroups: comp.os.minix,comp.sys.atari.st
Subject: Re: is Minix available for Atari 1040 ST?
Message-ID: <845@atari.UUCP>
Date: Thu, 17-Sep-87 14:04:16 EDT
Article-I.D.: atari.845
Posted: Thu Sep 17 14:04:16 1987
Date-Received: Sat, 19-Sep-87 09:59:18 EDT
References: <370@focus.UUCP>
Organization: Atari Corp., Sunnyvale CA
Lines: 26
Xref: utgpu comp.os.minix:1590 comp.sys.atari.st:4872

I know how the fork code for the ST's 68000 works in principle, but
the guys who are doing the port seem reluctant to enlighten anybody,
so here goes:

When you fork(), a copy of your data space is stored away in RAM.  The
parent continues executing, in the hopes that it will do a wait() right
away.  The child at this point is "ready but swapped out." When the time
comes to run the child, it gets swapped in -- the data space of the
parent and child are swapped.  This goes on until the parent wait()s for
the child, in which case the parent stays swapped out until the child
terminates, or until the child does an exec(), in which case it stops
using the same address space as the parent.  Remember that the
"swapping" going on is in RAM, not to disk or anything.

This is pretty rough -- I haven't looked at the details.  The basic
idea of shadowing two processes which run at the same address is right,
though.  Of course, if neither process does a wait or exec, as is
the case with tip(1), you end up doing a lot of swapping.  I don't
know what the performance ramifications are.

At least they share text (I think).

/----------------------------------------------\
| Opinions expressed above do not necessarily  |  -- Allan Pratt, Atari Corp.
| reflect those of Atari Corp. or anyone else. |     ...lll-lcc!atari!apratt
\----------------------------------------------/