🚀 go-pugleaf

In article <1174@cpocd2.UUCP>, howard@cpocd2.UUCP (Howard A. Landman) writes:
> 
> Under MultiFinder, each program (except possibly the last one) must be
>specially coded to be "MultiFinder compatible" by calling WaitNextEvent
>instead of GetNextEvent (if I don't have them reversed).

Not true.  WaitNextEvent exists only to more effectively use the CPU.
GetNextEvent can cause a context switch as well.

>problem?  Because it only takes one or two programs which fail to do this
>before MultiFinder fails to grant any CPU time at all to the lowest
>priority task.  Why is this a problem?  Because there are lots of Mac
>programs out there which were written before MultiFinder and are still

Your arguments are valid in general, but the particular case you site does
not occur.  99% of Macintosh application call GetNextEvent regularly, and
such applications work fine in the MultiFinder environment.  

If an application is computing some result, then it might not be calling
GetNextEvent.  But some applications do call it while computing (in order to
test for a cancel request), and these application will yield the CPU to
lower priority tasks.

> This was too restrictive, so MultiFinder was invented AS A KLUDGE to allow
> background tasks to run IF THEY WERE SPECIALLY CODED.  But not everything is,
> or ever will be.

This is not strictly necessary.  A background task does not need to call
WaitNextEvent.  There are some (pre-MultiFinder) public domain programs that
run fine in the background.  These are the programs that call GetNextEvent
while doing some computation.  It turns out that the logical way to allow
the user to cancel a long computation involves calling GetNextEvent, and
such programs will run in the background very nicely.

-- 
		 Larry Rosenstein,  Object Specialist
 Apple Computer, Inc.  20525 Mariani Ave, MS 32E  Cupertino, CA 95014
	    AppleLink:Rosenstein1    domain:lsr@Apple.COM
		UUCP:{sun,voder,nsc,decwrl}!apple!lsr