On Thursday, 8 October 2020 14:33:59 PDT Philippe wrote: > > > Thiago Macieira <[email protected]> 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 _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
