Theory About Timer Function and Event

[joniveehernandez]

Hi Guys, I'm wondering about how the Time works in LSL. This is important thing that I must know so that I can put a proper interval in my script. e.g.

If I set llSetTimerEvent to 5 seconds, where it means it triggers the time event every 5 seconds. Is the llSetTimerEvent will continue the countdown back to 5 seconds while your script in time event currently executing? or llSetTimerEvent will continue the countdown after the after the time event is finished? ~Thanks!

[Qie Niangao]

float lastTime;default{    state_entry()    {        llResetTime();        llSetTimerEvent(5.0);    }    timer()    {        float now = llGetTime();        llOwnerSay("Time since last sample = "+(string)(now-lastTime));        lastTime = now;        llSleep(4.0);    }   }

 What does this tell you?

(If you can't get in-world to test, the timer() event behaves like an interval timer, more or less. The interval is not restarted at the end of event processing.)

[Darkie Minotaur]

In principle, Qie is right - there are at least two things tht you have to keep in mind:

1. Lag can delay the timer
2. If the code in your timer event takes longer to execute than your timer length, this will delay your timer

[joniveehernandez]

That is clear now even you put 4 seconds delay the interval continues. 1 more thing this means also while the timer event still processing and the interval triggers again the timer event, does it conflict with the first process? Because I'm going to use it on my Security Orb that scans the area every 5 seconds and process all those agents.

[Ela Talaj]

When you call llSetTimerEvent() you basically request the server OS to add your script to a software timer queue. There are several of these queues fed from OS software timers: 1sec timer, 100 msec timer and in certain cases 10 msec timer. All these timers are in turn fed from the hardware clock, which is much much faster so they just count the ticks. When for instance 1sec timer counts enough ticks for 1 sec to expire, it checks the queued elements and subtracts 1sec from their timing periods. If some now have zero, it sends signals to those scripts (that is what the script timer event receives) and restores the original timing periods (which does require some queue manipulations).

It may seem that the OS software timer's  accuracy would depend on how many scripts are queued but that is not correct. In real-time programming there are several ways to construct timing queues in such a way that it does not matter how many elements are queued. What matters is that each task in the server is assigned a certain priority and those with higher priorities pre-empt lower priority ones. Application timers are usually medium priority so when the server has more important things to do the timers may be pre-empted and don't get to run unless those more important things are completed. That is a primary cause of time dilation.

[Qie Niangao]

If you're asking what I think you're asking, no, subsequent events won't conflict with ongoing processing of an earlier event. Conceptually, a script executes as a single thread; while it's handling one event, any other events get queued for later (until the queue is full, then some events get pushed out and missed).

[Innula Zenovka]

Given the reference to this being for a security orb, I think the question may be to do with what happens if you're calling llGetAgentList every 5 seconds and then find yourself calling llTeleportAgentHome, thus sleeping the script for 5 seconds for each agent.

I usually dodge that sort of problem by sending a link message to a helper script telling it to do things that are going to sleep the script, if I'm worried about such delays, but what happens if he's got several people to leleport home inside the one timer event?    Does the timer fire, and call llGetAgentList again, as soon as the script wakes up after teleporting the first person home, and, if it does, when does the second agent get teleported home and what effect does the sleep thus caused have on things?

 

 

 

 

 

 

[Qie Niangao]

Well, llTeleportAgentHome() is a pretty nasty thing to do anyway, but fair enough. (Also, I don't know whether SVC-2516 ever got fixed, so it may be the only viable option on void-surrounded islands.)

Most likely, whatever is done to intruders, it's being done to all of them in a loop within the timer() event handler; the script will keep running that loop to completion.

Darkie's post got me thinking, however, and what I didn't realize until just trying it myself is that more timer events are not queued-up while the timer event handler is running. That's a good thing, so timers won't cause lag to snowball. But moreover, the logic seems to be pretty clever: As far as I can tell, it seems to restart the interval iff it expires during event processing, rather than just catching the next edge of the original interval as it comes around (as it does if the interval does not expire during event processing). That's being even nicer to a lagging sim, and probably more intuitive for most scripts, but it's quite a deviation from my naive expectations based on handling POSIX itimer events.

(And so Darkie's comment about lag affecting timers is especially apt, and one delayed interval will not be followed by one that's shorter than normal if lag clears.)

And yeah, absolutely: Use a helper script to avoid such complexities by removing delay-inducing function calls from the event handler.

[joniveehernandez]

Innula you mean helper, pass those agent to a seperate script that will manage the ejecting of agents? Separate script for scanner and separate script for eject?.

Qie is it cleaver if after 5 seconds I'll stop the interval after the timer event is finish i'll call again the interval. It's like finish the process before firing again the next countdown.

[Innula Zenovka]

Yes, that's what I meant -- send uuids via link message to a separate script that handles functions with a build-in delay, when I don't want to worry about the delay affecting the main script.

[Qie Niangao]

You could stop and restart the timer within the timer() event handler, but you really don't need to. What I found was that your events will fire every five seconds unless you're not done processing the last event, in which case it will wait a full five seconds after you finish processing. So, basically, it's already doing what you'd do, in just those cases where you'd most want to do it.

I don't mean to speak for Innula, but yeah, a helper script would be just what you describe, where the scanner script sends llMessageLInked() to the helper eject script's link_message() handler. There are several different situations where you need separate helper scripts in LSL; it's not always to manage asynchronous processing as in this case. Some uses require multiple helper scripts.

The reason you probably want it in this application, however, is not that the script is going to do something stupid with its timer, but rather that you likely support some sort of user interaction, and if the script is stuck in llTeleportAgentHome for five seconds, that's a really long time for a user to wait for any response from the script.

[joniveehernandez]

What if the scanner script send 5 agents to the helper script? That will cause 25 seconds to process but after 5 seconds the scanner will sends another agent how can I handle those new batch of agents? we're not saying there will be new agents arrives within 5 second but still we need to intimidate all the possible scenarios. Is this where the multiple helpers come out?

[Qie Niangao]

Sorry, I missed this post for follow-up. Yeah, you could have multiple helpers if it's really important that they all poof simultaneously, or if (god forbid) there will be peaks in workload that exceed the event queue of a single helper script. For this application, though, I very much doubt that you'd need to worry about that, and the helper script will eventually catch up with all the agents its supposed to kick, just by working through all the events that get queued to it.

I suppose, to be safe, the main "scanner" script should keep track and make sure that the agents it asked the helper to kick do in fact disappear within some reasonable interval, and failing that, try kicking them again.