Timer threads interruptability

[deo]

Can't understand why in the following only first Sub1 works and never Sub2, they must be interruptable each 15 ms?
And if you comment "sleep 2000" then only Sub2 will work

Code: Select all

#Persistent

SetTimer,Sub1,-1
sleep 2000
SetTimer,Sub2,-1
return

Sub1:
Loop
{
  tooltip sub1
  sleep 500
}
return

Sub2:
Loop
{
  tooltip sub2
  sleep 100
}
return

[swagfag]

u start Sub1. in 10 to 16ms from now(no, not 1ms in fact) the timer will run once
next u hit Sleep and start sleeping
Sub1's timer is finally run after u have sleept a tiny amount and the sleeping is interrupted. u enter an infinite loop after which no other commands are run besides those in the loop body.

if u comment out the sleep, both settimers have enough time during the 10-16ms gap to initialize themselves.
then Sub1's infinite loop is entered(its body need not be executed), which gets interrupted by Sub2's infinite loop a short while after. now ure stuck in the second infinite loop

the takeaway is timers are interruptible, loops arent

[deo]

so even if i include "sleep -1" inside the loop there is no way to let another sub run?

[gregster]

Why not use a timer instead of a loop ? Or multiple...
(not a one-time-timer obviously)

[deo]

Why not use a timer instead of a loop ? Or multiple...
(not a one-time-timer obviously)

yea, actually this sounds like solution, thanks

[pneumatic]

the takeaway is timers are interruptible, loops arent

Loops can be interrupted as long as they're not Critical, or at a higher Priority than the thread trying to interrupt it, or inside the script's exit routine.

Can't understand why in the following only first Sub1 works and never Sub2, they must be interruptable each 15 ms?

The problem is that nothing is trying to interrupt Sub1.

i.e once Sub1 enters its loop, there's no reason for the main autoexec thread (which is sleeping for 2000ms) to try and interrupt it again.

It's not like the autoexec thread is its own timer which is firing to try and regain execution.

All it did was spawn a thread (Sub1) which interrupted it, and now Sub1 is still busy doing its thing.

There is no reason for the autoexec thread to try and interrupt it.

Other threads can interrupt Sub1 though, such as Sub2 (which hasn't been created yet), or hotkeys, or window messages.

A possible solution (I'm not exactly sure what you're trying to achieve):

Code: Select all

#Persistent
Critical  ;prevents the timers from interrupting this thread
SetTimer , Sub1 , 500
SetTimer , Sub2 , 100
Sleep 2000
Critical , Off  ;normally this isn't needed, but I recall experiencing a strange issue specifically relating to Critical in the autoexec section
return

Sub1:
Critical ;prevents Sub2 from interrupting it on the minute chance it happens to fire during this thread
Tooltip Sub1
return

Sub2:
Critical ;prevents Sub1 from interrupting it on the minute chance it happens to fire during this thread
Tooltip Sub2 
return

However you may notice the tooltip doesn't alternate with a repeating, predictable pattern. This is due to the timers only being accurate to the nearest 15ms approximately (depending on the system).

This causes the two timers to be slightly nudged out of sync, and once the error gets large enough one of them gets to run an extra time, and you get an unexpected pattern. To see what actually happened, right click the tray icon - Open - View - Lines most recently executed.

I'll try and come up with a solution for precise timing.