Re: Alternative to Delay()
Re: Alternative to Delay()
- Subject: Re: Alternative to Delay()
- From: Brian Willoughby <email@hidden>
- Date: Tue, 29 Jul 2003 12:53:15 -0700
[ This is not the same principle as say, checking a mouse state in
[ a while loop which would no doubt spin around at least thousands
[ of times per second which would in fact monopolise the processor.
[ In that case nowadays we can use TrackMouseLocation in a loop
[ which does this without hogging the processor and is an official
[ documentation recommended procedure.
One thing to consider is that there are many levels of "nice" coding
techniques for multi-processing.
The "busy loop" you mentioned first is not nice at all, since it takes as much
CPU as the system will give it, but produces no real results because all it is
doing is polling for a change in the mouse state.
However, despite the official documented recommendation, a loop calling
TrackMouseLocation is still not the nicest coding technique in terms of
multi-processing and user interaction. Such a loop simplifies the programmers
job, but does not always use the CPU efficiently. As a rule, any time the code
is looping while polling for a change in state, this code is wasting some
amount of CPU.
The best multi-processing techniques are to write your code so that it is
completely event driven and re-entrant. When you handle mouse down, for
example, set some state variables and remember some coordinates and then
return. Then, your application is not taking any CPU or executing any
instructions until the next event comes in. If the next event is a mouse moved
event, your handler can use the state variables and starting mouse position to
display any intermediate results, update appropriate state variables, and
again return without looping. You will eventually receive a mouse up event
which should signal the final result that the user's mouse drag gesture
indicates. By returning immediately after processing a single event, you
guarantee that your app is not taking any more CPU than the absolute minimum
needed.
Coding in this third method is not traditional Mac programming. It also may
only be possible in Cocoa (I've never written a pure Carbon app). And, most
important, many programmers have trouble organizing their code this way without
the convenient localization of a loop. But it is the only way to be totally
re-entrant and avoid excess CPU instructions that a looping construct creates.
Fewer instructions means less CPU usage. Event loops are a crutch :-)
Brian Willoughby
Sound Consulting
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.