Path: utzoo!attcan!uunet!zephyr.ens.tek.com!tektronix!psueea!jove.cs.pdx.edu!kirkenda
From: kirkenda@jove.cs.pdx.edu (Steve Kirkendall)
Newsgroups: comp.sys.atari.st
Subject: Re: Multitasking
Message-ID: <1610@psueea.UUCP>
Date: 17 Aug 89 05:50:36 GMT
Sender: news@psueea.UUCP
Reply-To: kirkenda@jove.cs.pdx.edu (Steve Kirkendall)
Organization: Dept. of Computer Science, Portland State University; Portland OR
Lines: 43


It's my turn to talk now.  I promise to try and say something original.

1) Why do I want multitasking? Well, mostly because it would make desk
accessories obsolete;  each DA could be replaced by an application program.
DAs use memory from the time the system is booted to the time it is rebooted.
This is bad.  You have to reboot the system to install a new DA.  This is bad.
DAs must be written and compiled differently than "regular" programs.  This is
bad. Presently we must worry about two kinds of programs ("*.ACC" and "*.PRG").
This is bad.  In fact, the only good thing about DAs is that you can run one
while you're in the middle of an application, and a REAL multitasking system
would give that ability to EVERY program.

Also, there are times when it is easier or more efficient to implement a single
application as a collection of tasks.  An example of this from UNIX is the
'cu' program, which is implemented as two processes: one to copy characters
from the keyboard to the modem, and one to copy characters from the modem to
the screen.  "Client/Server" systems (such as X-windows and certain database
packages) provide more examples.  The Minix kernel and AmigaDos are both
implemented as collections of tasks, because they are easier to maintain
that way.

2) One thing I wonder about, though:  what would multitasking TOS look like?
I mean "look" literally -- how would several GEM programs *share* the screen?
Currently, it seems that every GEM program expects to have exclusive control
of the screen.  Each handles its own refreshes, and has its own menu bar.
How does DRI's multitasking 80x86 version of GEM handle this?

3) Concerning the necessity of an MMU:  Obviously, an MMU is not *necessary*,
since Minix works.  Just as obviously, an MMU is *desirable* because it
limits the damage from a program on the rampage (pardon the pun), makes
debugging easier, eliminates the need for relocation, etc.  I want an MMU,
but I don't have one, and I'm not going to let that keep me from using
multitasking under Minix.

Even without an MMU, Minix-ST is fairly secure.  It traps stack overflow and
any attempt to dereference a NULL pointer.  It does NOT trap pointers that
overrun a buffer, but these are rare and typically occur only in the last
process that I have started (and hence in the process that resides in the
last portion of used memory) so no harm is done to other processes.
	-- Steve Kirkendall
	      ...uunet!tektronix!psueea!jove!kirkenda
	or    kirkenda@cs.pdx.edu