Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!jarthur!nntp-server.caltech.edu!toddpw
From: toddpw@nntp-server.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple2
Subject: Re: Multitasking on a II
Message-ID: <1990Dec16.073531.1483@nntp-server.caltech.edu>
Date: 16 Dec 90 07:35:31 GMT
References: <11297.apple.net@pro-angmar>
Organization: California Institute of Technology, Pasadena
Lines: 35

rhyde@ucrmath.ucr.edu (randy hyde) writes:

(Re : "I'd much prefer a truly multitasking GS/OS..")

>That is the most reasonable thing I've heard anyone post here in a
>long time.

>Actually, I'd settle for multiprogramming rather than multitasking,
>but most people confuse the two anyway.  If Apple would add a process
>manager to the toolbox, GS/OS would be great.

Let me second that. The toolbox already supports user ID's, and could be
patched to keep track of who's started which tools and so on. This
would help avoid A LOT of problems with DA's (and other processes) starting
tools and shutting them down without giving the foreground application a
serious headache.

The real barrier is GS/OS. There is a good deal of application context (33 or
so prefixes, the file level, and such) which is a real pain to switch among
processes from outside, but would be really easy for GS/OS to do internally.

Apple is turning the Mac O/S into a patchwork quilt trying to force it to 
provide real multitasking/multiprogramming support. The GS Toolbox and O/S
were far better designed for it, but the guys who laid out the actual tool
calls screwed it up. All of the tools should have used UserID's to keep track
of who's using which resources -- this support can be patched in but it should
have been there in the first place.

By the way, atomic instructions are NOT required for process communication,
as Randy said (BTW Randy, Using 6502 Assembly Language was my
first ML textbook) -- lack of them just makes it tougher. However, the 6502
has always had INC/DEC, which are atomic

Todd Whitesel
toddpw @ tybalt.caltech.edu