Found a QTimer tick-drop bug : deep dive into EventLoop blocking and a minimal reproducer

While testing a time-sensitive feature in Qt, I noticed my 100㎳ timer was actually firing every ~115㎳, causing missed ticks. Here's what I found. Root Cause The setup had two threads: MainThread — runs a QTimer (100ms interval) and handles taskFinished() signal WorkerThread — runs the actual task ( ~70ms ) The problem: onTaskFinished() runs on the MainThread via QueuedConnection , and its blocking work (~45ms) occupies the EventLoop long enough to delay or drop the next timer tick . tick elapsed_ms expected_ms drift_ms 1 101 100 1 2 216 200 16 3 331 300 31 4 501 400 101 ... Expected ticks: 100 | Actual ticks: 76 | Missing: 24 What I learned about QTimer internals QTimer fires through the EventLoop — if the loop is blocked, the timeout is delayed To compensate for Jitter, Qt calculates the next fire time based on the scheduled time , not the actual fire time Qt::PreciseTimer (available since Qt 5) disables power-efficiency batching for better accuracy QChronoTimer (new in Qt 6.8) adds n