tdf#98955 hardware_concurrency not ideal for thread pools
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/26254Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Showing
Please
register
or
sign in
to comment