Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!mips!apple!bc
From: bc@Apple.COM (bill coderre)
Newsgroups: comp.sys.mac.system
Subject: Re: Why I Would Like "True Multitasking"
Keywords: multi-tasking
Message-ID: <54465@apple.Apple.COM>
Date: 29 Jun 91 00:45:54 GMT
References: <1991Jun28.005152.5815@cs.sfu.ca>
Organization: Apple Computer Inc., Cupertino, CA
Lines: 58

lupini@cs.sfu.ca (Peter Lupini) writes:
|So here are my questions:
|1) Am I missing something obvious here?  I am assuming that I have to make my
|  program "multi-finder" aware or something, and make it be smart about not
|  taking all the cpu time while it is running.  This seems to be an incredible
|  pain when I'm just writing quick 'n dirty programs which may be used for 
|  only a week or so.

Peter: Without getting into a big argument about what "true
multitasking" is ("I dunno, but I knows it when I sees it") let me
just give you a pragmatic answer about writing your programs.

The bad news is: yes, you do have to write your programs in a special
way to allow Multifinder to switch them to the background.

The good news is: it isn't that hard to do, it ends up being pretty
much what you might think of doing in a non-multitasking OS, and the
code is available as templates and easily re-used.

The "Programmers Guide to Multifinder" from APDA provides the precise
details of how to do it, but so do several articles in MacTutor,
MacTechQuarterly, and other mac programming journals.

Code is available from APDA, from ftp.apple.com (I believe, I haven't
checked recently), and from those magazines.

I also believe that The Macintosh Programming Primer (volume 1, c or
pascal version) provides some sample code and explanations about the
methodology required.

The basic strategy revolves around the program's Main Event Loop. In
the "usual" form of this loop, the program checks to see if any events
are pending by calling GetNextEvent, then dealing with them.

In the Multifinder-friendly app, the program calls WaitNextEvent,
and then chooses what to do with events it receives belonging to it,
determined by whether or not it is "busy calculating".

The simple approach is to set a global flag (like gBusyCalculating)
when you have finished setting up to do the calculation. When the Main
Event Loop sees the flag set, it ignores most events (except, for
example, a command-period keypress), and instead calls a routine that
does a small amount of the calculation in question (for example,
DoOnePixel).

By tuning the parameters to WaitNextEvent, you can determine just how
much of your CPU will be eaten by the background processing.

This method requires a little code, but not a whole lot. Indeed, I
have a standard Mac Main Event Shell that I add to code I'm porting
from Unix that provides all the necessary operating system support
code I need. It even provides an acceptable user interface for no
particular extra charge.

There are obviously more issues to multitasking in the MacOS than I've
covered, but don't think it's very hard to do at all.

bill coderre
who actually wrote Mac code before Apple hired him