https://bugs.documentfoundation.org/show_bug.cgi?id=98955
--- Comment #3 from Michael Meeks <[email protected]> --- > So comphelper::ThreadPool spawns a fixed number of threads upfront, > regardless of how many are actually ever needed? Sounds odd. Don't think so - but we use the standard thread-pool <N> wide in where <N> is std::thread::hardware_concurrency() in a number of places: XLSX load, image scaling, and so on which are triggered reasonably commonly. Things like: sc/source/filter/excel/xetable.cxx: const size_t nThreads = nRows < 128 ? 1 : std::max(std::thread::hardware_concurrency(), 1U); Fall a bit foul of the '80 cores' there - which (anyway) are shared with a large number of other users =) > Not sure there's any support on any OS to determine such a concurrency > parameter that would be deemed useful in the given scenario. Fair enough; either way - I think it'd be reasonable for an administrator (or just when debugging) to have an environment variable / tweak-able to affect the maximum parallelism we want. Then again - no real need for it to go into sal/ I guess. Something like: sal_uInt32 getPreferredConcurrency(); somewhere would do the trick I guess; backending onto an env. var and the std::thread method. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
