summaryrefslogtreecommitdiff
path: root/comphelper/CppunitTest_comphelper_threadpool_test.mk
AgeCommit message (Collapse)Author
2020-10-05fix allocating thread pool workersLuboš Luňák
Tasks are removed from the queue before a worker starts working on it, which means that maTasks.size() is not the number of tasks to do, because the worked on tasks are not included there. This means the code could spawn only a smaller number of workers than were needed (and than CPU cores that are available). Change-Id: Ic6e6a79316cf48d82f2b80be7ad477b723b2c4e5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103955 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2017-04-21gbuild: Remove MSVC 2013 legacy codeDavid Ostrovsky
Uwinapi is discontinued. Change-Id: I063b4d0d8fab2d60de168e960a63b8181158ac01 Reviewed-on: https://gerrit.libreoffice.org/23198 Reviewed-by: David Ostrovsky <david@ostrovsky.org> Tested-by: David Ostrovsky <david@ostrovsky.org>
2016-06-15tdf#98955 hardware_concurrency not ideal for thread poolsAshod Nakashian
A new static member getPreferredConcurrency added to comphelper::ThreadPool to return a configurable max number of threads. By default the new function returns the hardware_concurrency value provided by std::thread. When MAX_CONCURRENCY envar is defined, the return value is limited to whatever is set there. Three call-sites that used std::thread::hardware_concurrency have been replaced with getPreferredConcurrency. Unittests added to cover the functionality of the new member. Unittests are capped to 4 threads. Change-Id: I3332e393a88a5ed436316fa712ed920a4b37f4af Reviewed-on: https://gerrit.libreoffice.org/26254 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>