Sivakatirswami wrote:
Aloha, Richard:
I got to see your picture from Andre's camera as you roamed the dry zone
in Nevada. We had a center in Virginia City for years. I loved the
silence of the desert!
After living in Los Angeles for so long, I consider it invaluable. :)
Anyway, I can now put a face to your name. The man who told me about
metacard years ago and i never looked back...(smile)
It's been a good journey, eh?
But if I'm not mistaken, didn't we first meet at a SuperCard conference
in '96? Or was that another gentleman from your ashram?
I have an interest in the above "send" issues...
You say "...then the repeat loop will continue, and DoSomething (like
all timer messages) will only be fired once the engine hits idle."
But, are they not piling up in the MessageQueue, to be executed, one
after another, never the less? And if params are sent along with the
cmd, are they also queued up?
That's my understanding: all pending messages are queued until idle,
which can raise concerns about the sort of race conditions the original
poster mentioned.
One of the best ways I've found to reduce CPU usage is to turn down the
frequency of any polling timers (timers that call themselves); for the
user there's often not much difference between 1/100th of a second and
1/20th, but it can take a huge load off the CPU to turn it down.
Also, in polling timers I've found it very helpful to first check to see
if a message is already queued before queueing it again, e.g.:
on DoPolling
DoSomething
if "DoPolling" is not in the pendingMessages then
send "DoPolling" to me in 200 millisecs
end if
end DoPolling
Without that check, if the time between idle exceeds the time to your
next pending message you can queue up redundant calls.
--
Richard Gaskin
Fourth World Media Corporation
___________________________________________________________
[EMAIL PROTECTED] http://www.FourthWorld.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
