Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!uwm.edu!linac!att!att!cbnewsk!ech
From: ech@cbnewsk.att.com (ned.horvath)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Questions about multitasking on the mac
Message-ID: <1991May12.210901.21908@cbnewsk.att.com>
Date: 12 May 91 21:09:01 GMT
References: <1991May12.150246.6287@potomac.ads.com>
Organization: AT&T Bell Laboratories
Lines: 36

From article <1991May12.150246.6287@potomac.ads.com>, by jtn@potomac.ads.com (John T. Nelson):
> 
> Calling WaitNeXTEvent and the DoEvent stuff fromwithin your program
> code "often" seems to be the way that multitasking is done on the Mac.
> Is this the way that ZTerm manages to do it's thing and yet be
> backgroundable?  I notice that Compactor Pro also is "backgroundable"
...

I didn't write either of these, but I've done similar kinds of apps...

The wait-now-and-then method is about all there is for essentially batch
processes like compaction (and compilation, linking, spreadsheet recalcs,
etc...).  Highly interactive programs call WNE anyway.  Comm programs are
running in the background because either they aren't busy, or they're doing
file transfers, and they're being clocked by external I/O.  It's fairly 
easy (well, I've been doing I/O programming for too many years, so *I*
think it's easy) to do file transfers driven by I/O complete events, 
which don't go through the usual Toolbox event queue.

To sketch the process, doing an XMODEM upload basically requires you to do
a disk read (which can be async if *ahem* your disk I/O can support async),
then a serial port write (async), then a serial port read (for the ack;
async, again) then either a retransmit (NAK) or start again with the disk
read.

The last paragraph is oversimplified, it's not intended to be a detailed 
design, but you can see how it's another event-driven process that really
does go on in parallel with whatever processes MultiFinder is managing.
A more sophisticated implementation would have a producer (disk read) feeding
a consumer (serial write) both free-running on I/O completes.  Assuming
ZTERM is this clever, there are actually three threads in the ZMODEM memory
space: disk I/O, serial I/O, and the user interface.
-- 

=Ned Horvath=
ehorvath@attmail.com