🚀 go-pugleaf

In article <4f6bag$ckp@news.mpd.tandem.com>, Joseph Crowe <jcrowe> wrote:

] that's it in a nutshell.  Oh, by the way, a clock program will not update in a
] CMT environment if you run an app that does not relinquish control of the CPU
] resource.  Believe it.
] 

Not necessarily.  The CMT environment may allow for interrupt driven tasks
that happen independent of the cooperative process loop.  For example, on
the MacOS, appletalk transactions happen preemptively such that network
traffic will preempt any application process, whether that process calls
WaitNextEvent() or not.

]    Yeah, but not all.  Think about this....you know all of those annoying
] alerts that essentially allow the user no alternative but to respond before
] doing anything else on the Mac?  Let's see, dialogue boxes in MacSpeak.  These
] are the indication that the underlying multitasking mechanism needs rework.  I

No, this means the application that uses the modal dialog, despite human
interface guidelines recommendations to avoid modes at all costs, is badly
designed.  You can trap user of X-windows into a mode just as easily.

DialogManager event loops DO yield the cpu context (they have to poll for
user events after all).  Thus background tasks WILL get cpu time (by
processing NULL events).  The problem with modes is that they trap all
USER events and restrict the users choices.  The (mis)use of modal dialogs
has nothing to do with any fundamental aspect of the underlying
multitasking model - this can happen on either a CMT or PMT system.

] don't have a problem with using Macs for their strengths....the Amiga is not
] yet an alternative for new technology anymore(Lightwave rendering on a
68040 is
] a pain...just as Raydream on my Quadra is a pain).  But to persistently deny
] that bits of the MacOS were flawed in conception and implementation puts you 

Who has denied this?  Who would bother denying it?  It is not relevant to
anything.

Cheers,

Dr. Mel Martinez
The Johns Hopkins University
Dept. of Physics
mem@jhu.edu