Should "dispatch" be extended for timers?

[Paul D. DeRocco]

> From: Peter Haworth
> 
> 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.

And if you want nonblocking operation with no delay, you specify a zero
time limit.

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

I think the purpose of "dispatch" is to report if/how the message is
handled, which implies blocking. I don't see what a dispatch with a time
limit would accomplish that can't be done with a "send". It's possible
that "dispatch" skips over the combining of the message and arguments into
a single string, and then breaking them apart again. On the other hand,
it's possible that the internal data structure that holds a message in the
timer list only stores a single string anyway, in which case "dispatch"
with a time limit would have no advantage at all over "send" with a time
limit.

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco at ix.netcom.com