[Development] Windows Timer Resolution: The Great Rule Change

[Thiago Macieira]

On Thursday, 8 October 2020 14:33:59 PDT Philippe wrote:
> > > Thiago Macieira <thiago.macieira at intel.com> wrote:
> > If nothing is signaled, why are they waking up at all?
> 
> Let me rephrase otherwise:
> if one calls WaitForSingleObject or WaitForMultipleObjects
> with a timeout of 1 millisecond, then these functions
> won't return before 15 milliseconds (provided the events don't get
> signaled during that period).

The Qt event loop uses MsgWaitForMultipleObjectsEx with a dwMilliseconds value 
of INFINITE. QTimer uses timeSetEvent from winmm.dll for any timer shorter 
than 20 milliseconds. Those are used because they have better precision than 
SetTimer. That means the event loop is woken up by signalling and should not 
be affected by the change you're talking about.

WaitForSingleObject is used with a timeout in qmutex_win.cpp and 
qwaitcondition_win.cpp (QMutex::tryLock and QWaitCondition::wait with non-
forever waits). These would be affected by the minimum-15ms sleep. I don't see 
a problem, because this type of timed wait is inherently racy. You have to be 
very careful how you program them, so please don't call QMutex:tryLock with a 
timeout greater than zero and don't use QWaitCondition with a timeout less 
than forever.

Finally, there's also a WaitForMultipleObjects with a fixed 100 ms timer in 
the adopted thread watcher thread function. (yes, it's a thread that watches 
the adopted threads)

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering