🚀 go-pugleaf

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