Can someone on the motoko team point me to where(or if it doesn’t exist, please explain) the exact workflow for timers set with setTimer in motoko?
I’ve put together the following list of things based on when the timers might run:
Context/Category
Question
Clarification
Timer Execution Timing
Do timers run at the beginning of a round or at the end of a round, or is there some other type of queue in place?
Clarifies the position of timer execution within a round.
Immediate Timer Execution
If I set a new timer with setTimer with a delay of 0, when will it run? Could it get picked up in the current round?
Addresses immediate execution scenarios for timers.
End of Round Scheduling
If timers run at the end of a round, how are they scheduled and what are the stipulations of their instruction limit?
Investigates the scheduling and limits of timers at the end of a round.
Timer Placement in Current Round
If a timer runs at the beginning of a round and I call setTimer with a delay of 0, does it get put at the end of the current round queue?
Looks into the behavior of newly set timers during the current round.
End of Round Timer Addition
If timers run at the end of a round, how would the process know it was getting low on time/instructions to execute?
Explores the feasibility and mechanics of adding timers at the end of a round.
Instruction Limit Impact
If the timers are at the end and my ingress functions chew up all the instructions, will my timers be skipped that round?
Examines the effect of instruction consumption on timer execution.
Timer Dominance
If at the beginning of a round, can a timer chew up all of your instructions during a round such that no ingress functions are called during the round?
Considers the scenario where timers could monopolize instructions.
@claudio@rvanasa@ggreif@luc-blaeser Wanted to ping on this before I write a bunch of exploratory code. Or maybe this is a better question for the replica team? If so, can you ping the right party into the conversation?
Motoko’s runtime system just adds a thin layer (basically just a priority queue, and upon changes therein a retransmission of the next desired absolute time for global timer expiration). So I’d pass this on to the execution team, as the callback is triggered from there. Pinging @berestovskyy as the principal developer for timers.
Just another ping for @berestovskyy for confirmation.
I did an experiment with Motoko playground and it seems that setting. A timer with a Duration of 0 seems to always run the next round. (I confirmed this by setting and appending the Time.now to detect which round I was on). Unfortunately, I forgot to save the playground link🤦♂️.
Sorry, folks, I’m still on vacation, but briefly. The timers might be scheduled only at the beginning of the round.
The instruction limit for timers is the same as for normal update messages. If timer handler finishes early, other messages might be executed afterwards within the same round.
To prevent timers to monopolize the execution, there’s a simple round robin scheduler between timers and other messages.
Hope that helps. I can provide more info with some links on Monday.
No problem. The timer/heartbeat scheduling logic can be found here.
Seems most of the questions are addressed in my previous message. Maybe, zero duration means to schedule the timer ASAP, which is likely the next round. However, due to scheduling logic, the actual execution might happen later.