🚀 go-pugleaf

In article <kevinbDMEBuq.173@netcom.com>, kevin@frobozz.sccsi.com (Kevin
Brown) wrote:

 
> Does WaitNextEvent() block until an event occurs, as its name implies?

The full call looks like:

   aBool = WaitNextEvent(eventMask, theEvent, sleep, mouseRgn);

If sleep (measured in 1/60th of a second) is set to 0, you get the CPU
back as soon as all the other processes are done with it.

> However, I doubt you're any more of a moron than I am, 

I never really thought you were a moron; that is why I question the really
silly arguments.  Misguided perhaps :-), but certainly not dumb.

> But it *is* a kludge.

Yup.  It just happens to be a kludge that works pretty well, most of the time.

> Now then...you *did* say "work well", didn't you?  Demonstrate that
> your solution will work "well" under a variety of conditions like,
> say, on many different speeds of CPU.

True.  You hint at a better solution later.

> Okay...fix the above code so that it will run optimally on all CPUs
> (i.e., not make too many or too few calls to WaitNextEvent() in any
> given period of time).  Aha...now you have to add a timing loop (to
> measure what "optimal" is) and some conditional code.

Exactly!  There is a machine global called Ticks (also in 1/60th of a
second) that I would check (although it isn't long-word aligned, which is
annoying on PowerMacs), that counts the number of ticks since the machine
was booted.  This is the recommended way to do CPU-intensive tasks.

> If it wasn't a
> kludge before, it definitely is now.

Yes, but it isn't very difficult code to write.

> is a *library* call that (a) can take an arbitrary amount of time to
> execute, (b) does not itself invoke WaitNextEvent(), and (c) you do not
> control but must, nonetheless, use (want to put it in the context of
> real life?  Okay...it could easily be an encryption library function).

If I really had to do this, I'd probably end up writing a preemptive
thread library.  Fire a timer (there are settable timers, but they are
restricted in what they can do, primarily because most of the MacOS,
including the memory manager, is non-reentrant), save the state, set up a
WaitNextEvent() call, return from timer, do the call, then restore the
state.  It would be a lot of work, but it certainly is possible.  It's
only software. :-)
-- 
        Nevin ":-)" Liber       nevin@CS.Arizona.EDU    (520) 293-2799