Path: utzoo!attcan!uunet!cs.utexas.edu!samsung!think!snorkelwacker!bloom-beacon!eru!luth!sunic!tut!santra!kampi.hut.fi!jmunkki
From: jmunkki@kampi.hut.fi (Juri Munkki)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Need info on multitasking capabilities on the mac
Message-ID: <1989Nov25.150030.800@santra.uucp>
Date: 25 Nov 89 15:00:30 GMT
References: <9775@zodiac.ADS.COM> <39178@srcsip.UUCP> <36687@lanl.gov> <74117@tut.cis.ohio-state.edu> <36755@lanl.gov> <1209@radius.UUCP> <2008@atanasoff.cs.iastate.edu> <9071@hoptoad.uucp> <1487@sequent.cs.qmc.ac.uk>
Sender: news@santra.uucp (Cnews - USENET news system)
Reply-To: jmunkki@kampi.hut.fi (Juri Munkki)
Organization: Helsinki University of Technology, Finland
Lines: 72

In <1487@sequent.cs.qmc.ac.uk> jeremyr@cs.qmc.ac.uk (Jeremy Roussak) writes:
>malign StuffIt.  There's an option in the preferences dialogue (yes,
>I'm English) to tell StuffIt to allow time to background tasks.

Setting this option doesn't help much. It seems that Stuffit stops from
time to time and uses that time to refresh a window and allow a few
task switches to happen. It then happily crunches for a few seconds
before pausing again.

This isn't what it should do. The feature is useless because you can't
really use a user interface that only reacts once every few seconds.
Just try any paint program and you'll see what I mean. The only thing
that it accomplishes is that some terminal programs might be able to
go on transmitting files (although very slowly). Task switching should
be allowed a lot more often. 5-10 times per second should be adequate.
The task switching overhead will not be too high, unless you allow
it to happen too often. 60 times per second is probably way too high.

The way I would implement regular task switching is that I would
keep a variable containing the next TickCount time at which the
program should pause. When it's time to pause, I'd save the current
TickCount and then call GetNextEvent to allow the task switch to
happen. I would then handle any pending update and suspend/resume
events that might be in the queue. After GetNextEvent returns,
it has switched to the foreground task, if our task is in the
background or it will have switched to one background task, if
our task is in the frontmost layer.

My routine should call TickCount again after the task switch.
If too much time has elapsed in the GetNextEvent, I might consider
changing the amount of time that I allow for my task. Since the
cause is probably another background task that is munching away
precious ticks, I would probably reduce the amount of time allowed
for my task. This allows interactive processes to run faster.
Usually you can just ignore that time spent in other tasks and
just add a few ticks to the TickCount value that was obtained
after calling GetNextEvent. This value then contains the amount
of time that we have to spend doing our own stuff. Really nice
programs allow the user to set that time. Some users might prefer to
have really slow background processing, but extremely fast fast
interactive processes, while some users might want just the
opposite.

Actually I don't have to do any of this in my terminal emulator.
The program is currently totally MultiFinder unaware, but is also
one of the most MultiFinder-friendly applications around*. Uploads
and downloads do not have their own event loops. They just get
regular calls from my main event loop, if they are active and
their timeout value has elapsed or my serial management routines
detect the they have received data. The time spent to calculate
a checksum and read or write the data is minimal.

The transfer window is updated every 1.5 seconds or when it receives
an update event. (This means that for 1.5 seconds, one part of the
window might contain different values than the other, but since the
time is so short, it doesn't confuse users. If the regular update
was every 25 seconds, some users might get confused by a window that
has been partly updated with data that does not match the other half
of the window.)

Hmmm... I originally intended this article as a short comment on
Stuffit task switching... How did it grow into this thing? I'd
still say that Stuffit is a prime example of bad task switching.

*  Since my application is not MultiFinder-aware, you might say that
   it is not really MultiFinder-friendly. I'm just reporting on what
   it feels like to use the application. ATP might disagree.

_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
|     Juri Munkki jmunkki@hut.fi  jmunkki@fingate.bitnet        I Want   Ne   |
|     Helsinki University of Technology Computing Centre        My Own   XT   |
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^