Just catching up on my posts to this list after some time...
Richard Gaskin wrote:
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?
Well I would never have gone to a conference, but I was using Supercard
from the day it was released. (color!) so you are right, we did "meet"
very early in the Supercard era/forums. It looks like some of my first
MC stacks are dated around 1999, so you were waving the flag for me to
take a look at Metacard well before that...
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.
Hmm, So obvious! But I've never done that... I guess because I was
assuming too much. I wonder how many of my spinning balls and delays in
some apps are run away pending message piling up....
where is the one and only location for all xTalks tips and tricks?
(hehe... old discussion, never comes to a conclusion...)
Thanks
_______________________________________________
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
