Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!mordor!jdb
From: jdb@mordor.s1.gov (John Bruner)
Newsgroups: comp.sys.mac
Subject: Re: UNIX and Mac applications on the Mac II
Message-ID: <7832@mordor.s1.gov>
Date: Tue, 28-Apr-87 21:31:45 EDT
Article-I.D.: mordor.7832
Posted: Tue Apr 28 21:31:45 1987
Date-Received: Thu, 30-Apr-87 04:17:24 EDT
References: <9519@duke.cs.duke.edu> <252@rocky.STANFORD.EDU> <4124@think.UUCP>
Reply-To: jdb@mordor.UUCP (John Bruner)
Distribution: world
Organization: S-1 Project, LLNL
Lines: 22
Keywords: UNIX, Mac II, multitasking, windows

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