Losing track of time

Dar Scott dsc at swcp.com
Mon Aug 11 15:09:00 EDT 2003


On Monday, August 11, 2003, at 01:16 PM, Howard Bornstein wrote:

>> The send is based on the date and time.  Though you specify it as a
>> delta, you are really creating a message that is readied for execution
>> at a time.
>
> Now you've got me confused. I thought the send parameter was a value in
> seconds, not a date & time. Obviously seconds can be converted, but 
> it's
> the lowest common denominator (other than ticks).

The form of the date/time is seconds.

> So doesn't it just set
> up an internal timer and "ring back" after so many seconds have 
> elapsed?

No.  (Virtually not and my guess would be really not.)  Even then, it 
doesn't matter.

>
>> Another is to calculate the delay in the send based on the time.
>> Calculate the seconds of the date/time you want the chime,
>> chimeSeconds.
>
> Isn't that exactly what I'm doing (minus the calculation) when I say
> "send 'reminder' to me in 3600 seconds"?

That is 3600 seconds from when the send executes (by the clock).

If there are any delays between the needed time and the actual 
execution of the send, then this delay is in all subsequent sends and 
can accumulate with this method.  If chime every hour for a week, these 
delays can add up.

You can minimize this if you send before touching any GUI or media.  Do 
it at the very top if you can.


>
> Ok, let's start all over. Tell me where I'm wrong in my thinking.
>
> 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.

I don't think it does that.  Even if it did, you still have problems.  
All events and ready queued messages are executed in order, of queued 
time, so other messages can cause delays.  The system can cause delays 
in the execution of a message.  The system clock (time and date) can be 
adjusted.  There can also be delays in the handler before the actual 
send.

> 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.
> Fortunately, I'm not trying to use this to navigate a space ship, so
> little delays aren't really a problem. I'm just curious.

You can time candidate blocking commands.  The action of a visual 
effect seems a candidate, if you are using that.

I misunderstood; I thought you were trying to avoid the accumulated 
error.

There are a few other possibilities of causes of problems (especially 
on Mac OS), but I can't think of anything that would cause a 5 second 
delay each cycle.  You might want to see if the Mac clock is keeping up.

Dar Scott






More information about the use-livecode mailing list