diff options
| author | Ivan Solovev <ivan.solovev@qt.io> | 2023-12-22 15:06:10 +0100 |
|---|---|---|
| committer | Ivan Solovev <ivan.solovev@qt.io> | 2024-01-08 18:29:26 +0100 |
| commit | 936e72d18075b79c8d29353618dfbd052ae59dae (patch) | |
| tree | 646a4f15bed717648ee990863a6993b8e3c4f351 /src/corelib/thread/qfutureinterface.cpp | |
| parent | 8ce261f6d857e8b05c8043042fce101cb95cd868 (diff) | |
Fix QThreadPool::maxThreadCount() usage
The docs claim that QThreadPool always creates at least one thread.
However, the user can (usually by mistake) request zero or a negative
number of threads.
The maxThreadCount() function is simply returning the value, that was
requested by the user.
Since it's a public API, it is used in several places in QtConcurrent,
where it is assumed that the value is always positive. This can lead
to a crash if the user sets zero as a maxThreadCount.
Update all such places with std::max(maxThreadCount(), 1).
Prefer this approach over changing the return value of
maxThreadCount(), because its behavior is documented and tested.
Amends 885eff053797d56f2e295558d0a71b030fbb1a69.
Fixes: QTBUG-120335
Pick-to: 6.7 6.6 6.5 6.2
Change-Id: Id3b2087cec7fbc7a2d42febca6586f2dacffe444
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Diffstat (limited to 'src/corelib/thread/qfutureinterface.cpp')
0 files changed, 0 insertions, 0 deletions
