Motoko - Timers - Specific Behavior

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.

1 Like