Should "dispatch" be extended for timers?

[Peter Haworth]

On Wed, Aug 27, 2014 at 10:42 AM, Michael Doub <mikedoub at gmail.com> wrote:

> 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.


I might be misunderstanding your explanation but not sure that's correct,
at least for dispatch.  Reason I say that is that you can immediately check
the it variable after a dispatch command to see it was handled or not.
 Plus, if you dispatch a function, you can get hold of the returned value
in the the result variable in the next line after the dispatch command.  So
it seems clear the the calling handler waits (or "blocks" in my
terminology) until the dispatched handler has completed before continuing.

I think send works the same way if it has no time specified. According to
the dictionary, a send with no time executes the "sent" handler
immediately, then execution of the current handler continues.  With a send
in time, the current handler finishes executing before the "sent" handler
is started.

Back to the original suggestion, I still think adding an in time to
dispatch would be a good idea. I'm just not sure how the ability to use the
it and result variables after a dispatch with an in time would work.

Pete
lcSQL Software <http://www.lcsql.com>
Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>