Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!gorgo.UUCP!bsteve
From: bsteve@gorgo.UUCP.UUCP
Newsgroups: mod.computers.68k
Subject: Re: forking around - final word on microtoys.
Message-ID: <8703140818.AA6217@gorgo.att.com>
Date: Sat, 14-Mar-87 10:35:04 EST
Article-I.D.: gorgo.8703140818.AA6217
Posted: Sat Mar 14 10:35:04 1987
Date-Received: Sun, 15-Mar-87 04:26:44 EST
Sender: mwm@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 33
Approved: info-68k@ucbvax.berkeley.edu

/* Bandygram for Mister Mongo... */

In article <8703080916.AA12728@gorgo.att.com> I wrote:
>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.

/* Bandy hits! */

>You're not paying attention.  What about pointers to data that you have
>malloc()ed?  You're either going to need an MMU (==data space relocation) or
>you're going to need to swap the data space around.

What I really meant was that you could do it. There are severe limitations
likely to be placed on the child process regarding what data sticks around.
There are actually ways to get around this, but they all generate lots of
overhead. We would prefer that forks take less than 20 ms.

/* Bandy hits again! -more- */

>This is why 68ks w/o MMUs (data and program relocation) are toy computers.

Agreed.

>  Enough already, people!

Further agreed.


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