Details
-
Bug
-
Resolution: Fixed
-
P2: Important
-
6.8.0
-
None
-
-
c57027199 (dev), d6c592aa2 (6.8), 4678d96d8 (dev), 1487d7edb (6.8)
Description
I observe a behavior change in 6.8.0: Despite setting setExpiryTimeout(-1) on QThreadPool, QThread::currentThreadId() returns more different IDs than maxThreadCount() would allow. Short program for testing:
#include <QCoreApplication> #include <QThreadPool> #include "qmutex.h" #include "qtimer.h" int main(int argc, char *argv[]) { QCoreApplication a(argc, argv); QThreadPool::globalInstance()->setExpiryTimeout(-1); QSet<int64_t> threadids; QMutex mutex; QTimer t; QObject::connect(&t,&QTimer::timeout,&t,[&threadids, &mutex]() { for(int i=0;i<10000;++i) { QThreadPool::globalInstance()->start([&threadids, &mutex]() { QMutexLocker locker(&mutex); threadids.insert(reinterpret_cast<int64_t>(QThread::currentThreadId())); qDebug()<<threadids.size(); }); } }); t.start(1000); return a.exec(); }
when running using Qt 6.7.3, the size of threadids does not exceed max threads (as desired), but it does when using Qt 6.8.0
Attachments
For Gerrit Dashboard: QTBUG-129898 | ||||||
---|---|---|---|---|---|---|
# | Subject | Branch | Project | Status | CR | V |
597402,2 | QThreadPool: fix regression with negative expiryTimeout | dev | qt/qtbase | Status: MERGED | +2 | 0 |
597576,4 | QThreadPool: handle negative expiryTimeouts | dev | qt/qtbase | Status: MERGED | +2 | 0 |
597608,2 | QThreadPool: fix regression with negative expiryTimeout | 6.8 | qt/qtbase | Status: MERGED | +2 | 0 |
598531,2 | QThreadPool: handle negative expiryTimeouts | 6.8 | qt/qtbase | Status: MERGED | +2 | 0 |