Xref: utzoo comp.sys.mac:14228 comp.windows.misc:353
Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!cornell!batcomputer!chow
From: chow@batcomputer.tn.cornell.edu (Christopher Chow)
Newsgroups: comp.sys.mac,comp.windows.misc
Subject: Re: A/UX window systems, Mac tool...( Hum Interface)
Message-ID: <4093@batcomputer.tn.cornell.edu>
Date: 21 Mar 88 02:51:01 GMT
References: <1174@cpocd2.UUCP> <6986@drutx.ATT.COM>
Reply-To: chow@tcgould.tn.cornell.edu (Christopher Chow)
Organization: Cornell Theory Center, Cornell University, Ithaca NY
Lines: 48

In article <6986@drutx.ATT.COM> clive@drutx.ATT.COM (Clive Steward) writes:
|
|In any Mac program, GetNextEvent () _is_always_called at the appropriate
|interval.  Since the beginning of Mac history, and presumably forevermore.
|
|In your own words, "NO SPECIAL CODING IS NEEDED.  Most programs multitask 
|AUTOMATICALLY without any...".
|
|The sole exceptions are non-user programs which take over the machine, such as
|memory testers or other diagnostic tools.  Same for any Unix box.
|

This is not necessarily true.  In any properly written Mac program
GetNextEvent() or WaitNextEven() is always called each time through the main
event loop.  But what determines how often the main even loop gets executed?

Sometimes you run tasks which are somewhat time critical.  Take for example,
downloading in the background under VersaTerm.  If I try to unstuff a large
StuffIt file, then StuffIt happily crunch away at its unstuff routine until
the large file is processed.  In the meantime, since MultiFinder is
non-preemptive, StuffIt holds control for the entire duration it takes to
process the archive file.  Unfortuantely, the downloading protocols have
time out period, and if the stuffit archive file is large enough then my
downloading session will terminate.  Without preemptive multitasking and
scheduling priorities, its impossible to guarentee that my downloading
session will not terminate due to time out errors.

I suppose that something like StuffIt can be rewritten to call
Get{Wait}NextEvent within the procedure which unstuffs a file, but then
we'll be violating the "no special coding necessary" rule.

Another problem with MultiFinder is that certain simple activity can
interrrupt the entire system.  For example, say you were downloading with
VersaTerm in the background, and doing a few things in another layer.  At
present, its possible to bring background downloading to a complete halt by
pressing the mouse down over a menu/menubar and just hold it there.  So now
I have to worry about how long I take to scan the menus of a new application
that I just downloaded if I'm downloading another one in the background.
Somehow, this dosen't seem right...

Christopher Chow
/---------------------------------------------------------------------------\
| Internet:  chow@tcgould.tn.cornell.edu (128.84.248.35 or 128.84.253.35)   |
| Usenet:    ...{uw-beaver|ihnp4|decvax|vax135}!cornell!batcomputer!chow    |
| Bitnet:    chow@crnlthry.bitnet                                           |
| Phone:     1-607-253-6699   Address: 7122 N. Campus 7, Ithaca, NY 14853   |
| Delphi:    chow2            PAN:  chow                                    |
\---------------------------------------------------------------------------/