Losing track of time

J. Landman Gay jacque at hyperactivesw.com
Mon Aug 11 15:56:02 EDT 2003


On 8/11/03 2:16 PM, Howard Bornstein wrote:

> Now you've got me confused. I thought the send parameter was a value in 
> seconds, not a date & time.

You specify the "send" time in a script as a time duration, but the 
engine converts that to a specific date/time and stores it in the 
pendingMessages as a specific point in time.

> You use send with a parameter of seconds. It goes off into Metacard 
> engine-land and probably sets up an OS timer. It then sits there fat, 
> dumb, and ugly (assuming you're doing nothing else, as in my case) until 
> the time elapses. Then it comes back to your app and says "It's Soup!". 
> It just counts seconds, right? Baring other system delays and blocking 
> operations, it should come back to you in the number of seconds you asked 
> for.

It doesn't really count seconds, it stores the trigger-time as a 
specific date/time. When that time becomes current, the message fires. 
If I say "send myHandler to me in 60 seconds" and the time is currently 
4:01 PM, the engine adds 60 seconds and stores the trigger time as "4:02 
PM" (not in that format, but you get the idea.) The engine checks its 
pendingMessages list every so often, and when it is 4:02 PM it fires off 
all the messages that are due, including "myHandler".

> All I'm trying to do is to see if the obvserved delay is due to other 
> system resources being used or if a blocking command (possibly "play" for 
> example) is happening or something else I haven't thought of. 

"Play" is not supposed to be blocking and subsequent lines of script 
will execute immediately after the sound has started to play. However, 
there may be a pause as the sound loads, especially for long sounds or 
sounds that have to be translated by QuickTime for example.

One other thing to look at is the "send" command itself. As I understand 
it, the command "send x to me" -- without a time value -- will send the 
message immediately, before the rest of the handler executes. If a time 
value is included -- "send x to me in 1 tick" -- the entire handler 
finishes executing before any message is sent to the queue. Even "send x 
to me in 0 ticks" will force the rest of the handler to execute before 
the message gets queued.

Since the only thing you are doing is playing a non-blocking sound, it 
doesn't seem likely that this distinction will make much difference, but 
it might. I'd also tend to think that background system tasks, mouse 
movements, virtual memory disk swapping, whatever, may also cause brief 
delays. The lag could be caused by something totally outside 
Revolution's control.

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com




More information about the use-livecode mailing list