dacf9961da
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 Change-Id: I3d98337103031c9bdf0bf365295f245be0c66aa7 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> |
||
---|---|---|
.. | ||
qatomicint | ||
qatomicpointer | ||
qfuture | ||
qfuturesynchronizer | ||
qfuturewatcher | ||
qmutex | ||
qmutexlocker | ||
qreadlocker | ||
qreadwritelock | ||
qresultstore | ||
qsemaphore | ||
qthread | ||
qthreadonce | ||
qthreadpool | ||
qthreadstorage | ||
qwaitcondition | ||
qwritelocker | ||
thread.pro |