|author||David Faure <firstname.lastname@example.org>||2013-06-24 19:20:24 +0200|
|committer||The Qt Project <email@example.com>||2013-10-31 17:45:58 +0100|
QThreadPool: fix race at time of thread expiry.
The current synchronization mechanism was racy: decrementing waitingThreads and then hoping that the wakeOne will wake a thread before its expiry timeout happens. In other words, on timeout, a just-assigned task would never run. And then no other task would run, if maxThreadCount is reached. Fixed by using a queue of waiting threads (rather than just a count), and by moving the wait condition into the thread itself, so we know precisely which one we're waking up, and we can remove it from the set of waiting threads before waking it up, and therefore it can determine on wakeup whether it has work to do (caller removed it from the queue) or it expired (it's still in the queue). This is reliable, whereas the return value from QWaitCondition::wait isn't reliable, when the main thread has already decided that this thread has work to do. Task-number: QTBUG-3786 Change-Id: I1eac5d6c309daed7f483ac7a8074297bfda6ee32 Reviewed-by: Thiago Macieira <firstname.lastname@example.org>
Diffstat (limited to 'src/winmain')
0 files changed, 0 insertions, 0 deletions