Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!zrm
From: zrm@mit-eddie.UUCP
Newsgroups: comp.sys.mac
Subject: Re: UNIX and Mac applications on the Mac II
Message-ID: <5643@eddie.MIT.EDU>
Date: Wed, 29-Apr-87 08:50:25 EDT
Article-I.D.: eddie.5643
Posted: Wed Apr 29 08:50:25 1987
Date-Received: Thu, 30-Apr-87 06:58:39 EDT
References: <9519@duke.cs.duke.edu> <252@rocky.STANFORD.EDU> <4124@think.UUCP> <7832@mordor.s1.gov>
Reply-To: zrm@eddie.MIT.EDU (Zigurd R. Mednieks)
Distribution: world
Organization: MIT, EE/CS Computer Facilities, Cambridge, MA
Lines: 24
Keywords: UNIX, Mac II, multitasking, windows

In article <7832@mordor.s1.gov> jdb@mordor.UUCP (John Bruner) writes:
>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

Quite right! Scratch what I said about blocking on a lack of events.
As an example, I wrote a program that calculates the Mandelbrot
fractal and plots it. To remain interactive, it polls the event
manager so that you can at least run DAs while it is cruching away at
the fractal. Really, any application that works on something, like
background printing, and remains interactive would be completely
screwed by blocking on a lack of events.

That means that a Macintosh running Unix and a Macintosh application
would be faced with the serious problem of a having a task that is
always runnable and hardly ever doing anything useful with its time.

Has Apple asked developers what they want in multi-tasking? I could
make do with some rudimentary stack switching and a re-entrant memory
manager (if it isn't already). And a place to put background tasks
(e.g. a third heap zone) would be nice. With that, one could implement
background processing very nicely.

-Zigurd