what actually happens when sending a message out of a repeat loop?

[Tiemo Hollmann TB]

Hi all,

perhaps a question, where I shouldn't have to think about, because it works,
but I would like to know what happens behind the scenes.

I have a repeat loop and send a message to another handler from within the
repeat loop with parameters, which change every loop.

If using a function call instead of the message, the main handler would wait
until the function returns back, but when sending a message, the loop is
running on. So what happens now, if the sub handler takes "much longer" as
the main handler and the loop turns hundred of times. Will all the send
messages to the sub handler with the changed parameters kept in the
messagequeue safely and being processed, even after the main handler has
finished already? Are there any limitations in message numbers or size of
this messagequeue?

 

Thanks for sharing

Tiemo

 

 

 

_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Richard Gaskin]

Tiemo Hollmann wrote:

> I have a repeat loop and send a message to another handler from within the
> repeat loop with parameters, which change every loop.
>
> If using a function call instead of the message, the main handler would wait
> until the function returns back, but when sending a message, the loop is
> running on. So what happens now, if the sub handler takes "much longer" as
> the main handler and the loop turns hundred of times. Will all the send
> messages to the sub handler with the changed parameters kept in the
> messagequeue safely and being processed, even after the main handler has
> finished already? Are there any limitations in message numbers or size of
> this messagequeue?

When you send a message like this:

   repeat 100
    send "DoSomething" to btn "SomeScripts"
   end repeat

...it executes DoSomething and only returns to the calling handler when
DoSomething finishes.

But if you use this form:

   repeat 100
    send "DoSomething" to btn "SomeScripts" in 10 millisecs
   end repeat

...then the repeat loop will continue, and DoSomething (like all timer
messages) will only be fired once the engine hits idle.

Are you using the "send...in <time>" form?

If not, we may need to see your scripts to figure out what's going on there.

--
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com
_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Tiemo Hollmann TB]

Hi Richard,
oh that's new for me. My loop looks like this:

repeat 100
        doSomething
end repeat

on doSomething
        something
end

I didn't knew that the calling handler waits for the execution of a message
handler. I thought that it would only wait, if you use a function call, like

Repeat 100
        Get doSomething()
end repeat

Thanks for clarifying
Tiemo

>
> When you send a message like this:
>
>    repeat 100
>     send "DoSomething" to btn "SomeScripts"
>    end repeat
>
> ...it executes DoSomething and only returns to the calling handler when
> DoSomething finishes.
>
> But if you use this form:
>
>    repeat 100
>     send "DoSomething" to btn "SomeScripts" in 10 millisecs
>    end repeat
>
> ...then the repeat loop will continue, and DoSomething (like all timer
> messages) will only be fired once the engine hits idle.
>
> Are you using the "send...in <time>" form?
>
> If not, we may need to see your scripts to figure out what's going on
> there.
>
> --
>   Richard Gaskin
>   Managing Editor, revJournal
>   _______________________________________________________
>   Rev tips, tutorials and more: http://www.revJournal.com
> _______________________________________________
> use-revolution mailing list
> use-revolution@...
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution

_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Sivakatirswami]

Richard Gaskin wrote:

>
> When you send a message like this:
>
>   repeat 100
>    send "DoSomething" to btn "SomeScripts"
>   end repeat
>
> ...it executes DoSomething and only returns to the calling handler
> when DoSomething finishes.
>
> But if you use this form:
>
>   repeat 100
>    send "DoSomething" to btn "SomeScripts" in 10 millisecs
>   end repeat
>
> ...then the repeat loop will continue, and DoSomething (like all timer
> messages) will only be fired once the engine hits idle.
>
> Are you using the "send...in <time>" form?
>
> If not, we may need to see your scripts to figure out what's going on
> there.
>

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!  Then they started in with the open strip mining
and the road past our place (The old famous brewery just down the hill
from main street) became a main road for commuters to Carson City and
the atmosphere was pretty much lost forever.

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)

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?

I've seen issues with CPU getting eaten alive and other "memory" issues
which I do not fully understand, but I know relate to this messagequeue
business and, like Tiemo, I would like to understand it better.

Sivakatirswami








_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Richard Gaskin]

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
  ___________________________________________________________
  Ambassador@...       http://www.FourthWorld.com
_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Eric Chatonet]

Bonjour Richard et Sivakatirswami,

Le 23 juin 08 à 18:45, Richard Gaskin a écrit :

> 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

I agree so much that I think that the engine itself could ignore sent  
messages that are already in the pending messages except when the  
delay is zero.

Best regards from Paris,
Eric Chatonet.
----------------------------------------------------------------
Plugins and tutorials for Revolution: http://www.sosmartsoftware.com/
Email: eric.chatonet@.../
----------------------------------------------------------------


_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Jan Schenkel]

--- Eric Chatonet <eric.chatonet@...>
wrote:

> Bonjour Richard et Sivakatirswami,
>
> Le 23 juin 08 à 18:45, Richard Gaskin a écrit :
>
> > 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
>
> I agree so much that I think that the engine itself
> could ignore sent  
> messages that are already in the pending messages
> except when the  
> delay is zero.
>
> Best regards from Paris,
> Eric Chatonet.
>

Hi Eric et al,

While I can see the advantages of Revolution
'collapsing' requests, I'm not sure this should be the
default behaviour - and definitely not if there are
parameters involved, as the sequence then becomes very
important.
Plus, what about timers that run every minute?

Jan Schenkel.

Quartam Reports & PDF Library for Revolution
<http://www.quartam.com>

=====
"As we grow older, we grow both wiser and more foolish at the same time."  (La Rochefoucauld)


     
_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Eric Chatonet]

Hi Jan,

Hope you are well.
Actually, I was thinking about new users.
The best thing is to enjoin all to use the form: if "DoPolling" is  
not in the pendingMessages then send "DoPolling" to me in x millisecs

Le 23 juin 08 à 20:35, Jan Schenkel a écrit :

> --- Eric Chatonet <eric.chatonet@...>
> wrote:
>> Bonjour Richard et Sivakatirswami,
>>
>> Le 23 juin 08 à 18:45, Richard Gaskin a écrit :
>>
>>> 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
>>
>> I agree so much that I think that the engine itself
>> could ignore sent
>> messages that are already in the pending messages
>> except when the
>> delay is zero.
>>
>> Best regards from Paris,
>> Eric Chatonet.
>>
>
> Hi Eric et al,
>
> While I can see the advantages of Revolution
> 'collapsing' requests, I'm not sure this should be the
> default behaviour - and definitely not if there are
> parameters involved, as the sequence then becomes very
> important.
> Plus, what about timers that run every minute?
>
> Jan Schenkel.
>
> Quartam Reports & PDF Library for Revolution
> <http://www.quartam.com>
>
> =====
> "As we grow older, we grow both wiser and more foolish at the same  
> time."  (La Rochefoucauld)
>
>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution@...
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>

Best regards from Paris,
Eric Chatonet.
----------------------------------------------------------------
Plugins and tutorials for Revolution: http://www.sosmartsoftware.com/
Email: eric.chatonet@.../
----------------------------------------------------------------


_______________________________________________
use-revolution mailing list
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Sivakatirswami]

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
use-revolution@...
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution