Should "dispatch" be extended for timers?

[Michael Doub]

I think blocking was just a poor choice of wording.   Here is my take on how it works:

Think in terms of the message queue being a stack.   A stack of things to do where the top entry is what is currently executing.  Entries blow it will be executed in sequence as the top entry is popped off.  

When you call a function or handler, the currently executing handler is paused and pushed onto the stack and the requested function or handler is added as the top.  Control returns the pushed entry when the top is finished and popped off.

The send with no time specified and dispatch, both inserts the called hander, just below the top entry on the stack to it will be the next to execute when the current top entry is finished.

Send with a time specified is a bit different in that it is inserted below the top entry of the stack at the time specified.  Obviously if there are no entries, it becomes the top entry.

This is my mental model of how things work.   Please correct me if I am incorrect.

Regards,
   Mike




On Aug 27, 2014, at 1:10 PM, Earthednet-wp <prothero at earthednet.org> wrote:

> I've wondered what, specifically, "blocking" means. Does it mean that there are no idle messages sent? What is being blocked?
> Bill
> 
> William Prothero
> http://es.earthednet.org
> 
>> On Aug 27, 2014, at 8:16 AM, Bob Sneidar <bobsneidar at iotecdigital.com> wrote:
>> 
>> You cannot dispatch in time. But you can send in time. If you:
>> 
>> send doSomething to me in 0 seconds
>> do someotherthingsfirst
>> 
>> then someotherthingsfirst will run and anything else that comes after it. doSomething will run the next idle message. 
>> 
>> Bob S
>> 
>> 
>>> On Aug 27, 2014, at 07:46 , dunbarx at aol.com wrote:
>>> 
>>> Richard.
>>> 
>>> 
>>> When you say "send" is blocking, in what way? Is this really any different that calling any handler? For example:
>>> 
>>> 
>>> on mouseUp
>>> doSomething
>>> end mouseUp
>>> 
>>> 
>>> on MouseUp
>>> send "doSomething" to this card
>>> end mouseUp
>>> 
>>> 
>>> Can you explain the difference?
>>> 
>>> 
>>> Craig
>>> 
>>> 
>>> 
>>> -----Original Message-----
>>> From: Richard Gaskin <ambassador at fourthworld.com>
>>> To: use-livecode <use-livecode at lists.runrev.com>
>>> Sent: Wed, Aug 27, 2014 10:18 am
>>> Subject: Re: Should "dispatch" be extended for timers?
>>> 
>>> 
>>> Peter Haworth wrote:
>>> 
>>>> Sounds like a great idea to me.  I seem to remember that one of
>>>> dispatch/send is blocking and the other isn't. Could that be a
>>>> possible reason for the lack of "in" with dispatch?
>>> 
>>> Both are blocking when called immediately; "send" can become on-blocking 
>>> by specifying a later time to send the message.
>>> 
>>> 
>>> dunbarx wrote:
>>> 
>>>> "Send' can, er, send parameters as well as a command. In a button
>>>> script:
>>>> 
>>>> on mouseUp
>>>> send "putArg" && random(99) && random(99)  && "XYZ" to me in 5
>>>> end mouseUp
>>>> 
>>>> on putArg var
>>>> put var
>>>> end putArg
>>>> 
>>>> You get pairs of random numbers and the text as well. All parameters
>>>> come across as a batch.
>>>> 
>>>> Or you can separate in the usual way:
>>>> on mouseUp
>>>> send "putArg" && random(99) & "," & any char of "ABCD" to me in 5
>>>> end mouseUp
>>>> 
>>>> on putArg var,var2
>>>> put var2 --or the first one or both
>>>> end putArg
>>> 
>>> Yes, both "send" and "dispatch" allow passing arguments, but as we saw 
>>> with yesterday's forum post it seems unintuitive to have to put quotes 
>>> around things that aren't strings, making "dispatch" feel more natural.
>>> 
>>> Of course in a certain Zen sort of way even variable names are 
>>> technically strings on some level, but having to quote them to pass them 
>>> with "send" is something I see a lot of newcomers guess wrong.
>>> 
>>> FWIW I submitted a request to have "dispatch" extended with "in" for timers:
>>> 
>>> <http://quality.runrev.com/show_bug.cgi?id=13287>
>>> 
>>> -- 
>>> Richard Gaskin
>>> Fourth World Systems
>>> Software Design and Development for the Desktop, Mobile, and the Web
>>> ____________________________________________________________________
>>> Ambassador at FourthWorld.com                http://www.FourthWorld.com
>>> 
>>> _______________________________________________
>>> use-livecode mailing list
>>> use-livecode at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>>> preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>> 
>>> 
>>> _______________________________________________
>>> use-livecode mailing list
>>> use-livecode at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> 
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode