🚀 go-pugleaf

One of the characteristics of GetNextEvent that some applications
depend upon is that it does *not* block if there is no event (hence
the "null" event).  For instance, well-behaved applications (written
for the current operating system) must repeatedly call SystemTask,
TEIdle, etc.  They may also want to do some explicit busy-waiting
on other things (e.g. the Ticks variable or background I/O that
doesn't call a completion routine).  A multitasking system can't
simply block a task if no event is ready for it.

There are workarounds -- the task could be blocked until the next
lbolt wakeup (er, ah, wrong operating system -- say for the next
59 ticks or so).  However, the current paradigm for Mac programming
is at a pretty low level (witness the use of timer constants to
set baud rates for the serial ports instead of small integers
which index an internal hardware-dependent table).  That, and the
large number of magic state variables in low memory, make it harder
to multiprogram programs written for the Mac O/S than programs
written for more conventional O/S environments.  (Harder, not
impossible.)
-- 
  John Bruner (S-1 Project, Lawrence Livermore National Laboratory)
  jdb@mordor.s1.gov	...!seismo!mordor!jdb		(415) 423-4848