send "subCheckNow" to me, or?

[Alex Tweedly]

Garrett Hylltun wrote:

>
> Before I try it I have one reservation which I note further down in 
> this reply.
>
>> NOTE that a ""delayed send" (such as "send xxx to me in N ticks") is 
>> commonly used, because it queues the message, and therefore affects 
>> the order of execution. As the docs say,
>
>
> I've got a delay of 500 milliseconds at the top of the handler.  This 
> was the full handler that I was using:
>
> on subCheckNow
>   wait for 500 milliseconds with messages  -- < Delay here
>   put field "fCounter" + 1 into field "fCounter"
>   if field "fCounter" > 1800 and field "fAppMode" is "1" then
>     get URL "http://www.411on911drivingschool.com/data/guestid.txt"
>     put it into field "fResult"
>     put "1" into field "fCounter"
>     if field "fResult" is field "fPrevious" then
>       put "Checked at:  " & short time into field "fStatusLabel"
>     else
>       put field "fResult" - field "fPrevious" into varDiff
>       put varDiff & " new message(s)" into field "fStatusLabel"
>       put field "fResult" into field "fPrevious"
>       set the visible of this stack to true
>       put "4" into field "fAppMode"
>       set the disabled of button "btnRefresh" to true
>       set the disabled of button "btnDismiss" to true
>       set the label of button "btnPause" to "Resume"
>       play audioclip "tick.wav"
>       wait 500 millisec
>       play audioclip "tick.wav"
>       wait 500 millisec
>       play audioclip "tick.wav"
>       wait 500 millisec
>       play audioclip "tick.wav"
>       wait 500 millisec
>       play audioclip "warn1.wav"
>     end if
>   end if
>   if field "fAppMode" is "1" then
>     send "subCheckNow" to me in 1 tick  -- < A 1 tick delay here
>   end if
>   if field "fAppMode" is "3" then
>     close this stack
>   end if
> end subCheckNow
>
> [snip]
>
>>
>> but there seems to be no reason to use the "immediate" send to the 
>> same handler.
>
>
> What I was worried about is the fact that just using the handler name 
> is kind of like doing a "GOSUB" in other languages, and that it 
> expects to return to it's original calling handler when the new 
> handler has completed.  SEND seems like a "GOTO" and doesn't return to 
> the calling handler.  Unfortunately I did not find info in the docs 
> that covered this aspect.
>
You need to be careful (i.e. precise) when you say that :-)
    send "xxx" to me in N ticks
is kind of like a (delayed) goto - the message is queues, then the code 
following the 'send'; statement is executed (so it's not really quite 
like a GOTO), and when the handler (and any calling handlers) exits, or 
a "wait with messages or other 'send in time' statement is executed) 
then the message queue will send the message

On the other hand,
   send "xxx" to me
is just not at all like a GOTO. The handler is executed immediately (via 
the message passing), but THEN the following code is also executed - so 
it's very like a GOSUB, and therefore very, very like just using the 
handler name directly; basically the only difference seems to be that 
it's less efficient.

So if you were doing simply 'send "xxx" to me' then you would still be 
building up a stack of calls; we can argue semantics whether it is 
officially called "recursion" or not - but the effect would be that all 
of these would have context that needs to be kept simultaneously.

(But your full example only does 'send in time', so your example is OK - 
no recursion, no stack of many contexts - but your reasoning above 
wasn't :-)

> What worries me more is, knowing that just calling the handler by name 
> is like "GOSUB", is a queue being filled up in the engine, just 
> waiting for the "GOSUB" like calls to be returned to their original 
> calling points.  And if they are not returned, what happens to the 
> queue that has built up?  And what will the engine do if that queue 
> gets too large?
>
> I know that in other languages this would likely lead to a crash.
>
> I think at the moment I'd better stick to using send until I can find 
> out whether the engine will get mucked up by using just the handler name.

The handler above looks to me like a good case of using 'send in time'.

-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date: 04/07/2006