summaryrefslogtreecommitdiffstats
path: root/util/local_database/xpathlite.py
diff options
context:
space:
mode:
authorDavid Faure <david.faure@kdab.com>2013-06-21 08:32:17 (GMT)
committerThe Qt Project <gerrit-noreply@qt-project.org>2013-11-15 11:42:27 (GMT)
commit605647f2b8a6c8d4f700732a7fcdb1dec3459231 (patch)
tree6be7022dec15c93aac99e4557ebcebc68b72b483 /util/local_database/xpathlite.py
parent521ea9cc0e4014ce5186c727ba30026d7b7edc60 (diff)
downloadQt-605647f2b8a6c8d4f700732a7fcdb1dec3459231.zip
Qt-605647f2b8a6c8d4f700732a7fcdb1dec3459231.tar.gz
Qt-605647f2b8a6c8d4f700732a7fcdb1dec3459231.tar.bz2
QThreadPool: fix counting of waiting threads
QTBUG-21051 has a testcase where activeThreadCount() could actually end up at -1 (converted to an autotest in this commit). The reason was: start() calls tryStart() which returns false due to too many active threads (reserveThread() causes this), so it calls enqueueTask() - which actually wakes up the waiting thread, but it didn't decrement the number of waiting threads. Note that tryStart() is "if I can grab a waiting thread, enqueue task and wake it" while start(), in case tryStart() fails, wants to "enqueue, and then if I can grab a waiting thread, wake it". This is why enqueue shouldn't wake; waking must happen only if we can grab a thread (d->waitingThreads > 0). Task-number: QTBUG-21051 Backport from qtbase/dacf9961da86751a59da0e84bc943fe0d1c8d95b Change-Id: I1e437da27b733a72b48ff1b6f2b78f81a7ed129b Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Diffstat (limited to 'util/local_database/xpathlite.py')
0 files changed, 0 insertions, 0 deletions