🚀 go-pugleaf

In article <649@apple.UUCP> huxham@apple.UUCP (Fred Huxham) writes:
>In article <252@rocky.STANFORD.EDU> ali@rocky.UUCP (I) write:
>>But most Mac applications are use busy-waiting in their main event loops,
>>no? It might be possible to run them as tasks, but they will all 
>>be "cpu-hogs". It seems like most old applications will not do too well
>>under a multitasking Mac II Finder.
>
>But most are just processing null events, waiting for events that they really
>want to handle.  If there was some way to only deal with "real" events and
>let null event time be shared, well that would be cool....

Well, one way to get around this is to start using "true" event based
input handlers --- using interrupts and all. (Of course that shouldn't mean
you have to go way down and grind interrupt code in assembly!) For
instance, in the Amiga, you can "sleep" until an event occurs with
the following type of statement:

  WakeUpBits = Wait (bitset);

This will cause the task to go to sleep. The scheduler will not awaken
this task until the an event specified in "bitset" occurs. For instance,
if you want the task to wake up on some user I/O (such as mouse or keyboard),
you might say "Wait (IDCMPSig)". If you also want a timer event to wake the
task up you might say "Wait (IDCMPSig | TimerSig)". This would be useful
in a game where things happened in real time (say every 5 seconds) but
you wanted to be able to capture user event at the time it happened...
You tell which event happened by looking at WakeUpBits. This method
of programming certainly beats...

  while not Button do;

when it comes to efficiency and proper behaviour in multitasking environments.

Seems like existing applications would have to be changed, but, if the
correct functions are added to the Toolbox, the changes in the
applications can probably be kept to a minimum. (Because, after all,
once you recieve the event (whether you busy wait or sleep) you have to do
the same sort of case-statement to determine what the event was and to
act upon it. So that part of the application would not have to be changed.) 

Ali Ozer, ali@rocky.stanford.edu