To join a thread, the mutex must be released - another thread
in pushTask() could add a new thread to maWorkers at that point,
which must of course not be deleted.
Avoid the problem by transferring ownership of the to-be-deleted
threads to the calling thread.
(regression from bdaa13a877)
Change-Id: I9d4fcfe4cb46a336586b5663934a12d47b2d8ccb
This takes a different approach than commit
9899ffd244.
Change the ThreadPool to automatically shutdown and join all threads
whenever waitUntilDone() is called. Then start the threads again
in pushTask().
Because the ThreadPool is meant to be used synchronously with
waitUntilDone() called after adding all required tasks, this should
obviate the need to call shutdown() before process exit, as
there won't be any threads running at that point.
Change-Id: I2b8e639004a94cf05ccb4522aa1f0d3dac88a936
Reviewed-on: https://gerrit.libreoffice.org/35510
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Jenkins <ci@libreoffice.org>
As it causes "unopkg.bin:
/home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/comphelper/source/misc/threadpool.cxx:96:
comphelper::ThreadPool::~ThreadPool(): Assertion `mbTerminate' failed."
in
<https://ci.libreoffice.org/job/lo_gerrit/8283/Config=linux_clang_dbgutil_64/console>
and also locally. Revert till it's clear if that assert() should be a
SAL_WARN() or unopkg has to be fixed.
This reverts commit 9899ffd244.
Change-Id: I72902f7da410012340aa8231d84c6871a3f7b976
Commit aa68c99d88 added some code using
std::condition_variable to comphelper.
Built with MSVC 2017, this causes many cppunittester.exe processes to
deadlock in ThreadPool::shutdown():
maTasksChanged.notify_all();
This ultimately calls NtReleaseKeyedEvent(), which never returns.
The reason appears to be a bug in Windows 7, for which a "hotfix"[1] is
avaiable here, but it's apparently not distributed via Windows Update
so we likely can't rely on users or even developers having this installed.
However, the documentation of DllMain[2] and ExitProcess[3] indicates
that during shutdown, by the time global destructors are invoked
all threads other than the one that called ExitProcess have already
been terminated.
Returning from main() implicitly calls ExitProcess [4].
As it turns out the problem only happens for some CppUnitTests because
soffice.bin will call ThreadPool::shutdown() from Desktop::doShutdown()
while it is still safe.
[1] http://support.microsoft.com/kb/2582203
[2] https://msdn.microsoft.com/en-US/library/windows/desktop/ms682583(v=vs.85).aspx
[3] https://msdn.microsoft.com/en-us/library/windows/desktop/ms682658(v=vs.85).aspx
[4] https://blogs.msdn.microsoft.com/oldnewthing/20100827-00/?p=13023
Change-Id: I6137461ca7efe9a5fbe4f8f8478fb96de3570469
Reviewed-on: https://gerrit.libreoffice.org/35066
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Assume T0 calls ThreadPool::pushTask twice, then ThreadPool::waitUntilDone:
T0 calls ThreadTaskTag::onTaskPushed:
mnTasksWorking = 1, maTasksComplete.reset
T1 runs the 1st task to completion and calls ThreadTaskTag::onTaskWorkerDone:
mnTasksWorking = 0; suspended...
T0 calls ThreadTaskTag::onTaskPushed:
mnTaskWorking = 1, maTasksComplete.reset
T1 continues in the call to ThreadTaskTag::onTaskWorkerDone:
..., maTasksComplete.set
T0 calls ThreadTaskTag::waitUntilDone and immediately returns
T2 only now starts to run the 2nd task
Change-Id: Ic29101a4791fca2a1a4d54b559f10ff706e8a20d
If more than one place in the code submits tasks to the shared
pool, then waitTillDone() becomes unreliable.
Add a tagging mechanism, so different callsites can wait
on different sets of tasks.
Also try to protect our worker threads against exceptions from
the thread tasks code.
Change-Id: Idde664ab50008d31a2dd73910bb22f50e62ae22f
Reviewed-on: https://gerrit.libreoffice.org/27042
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
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:🧵: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>
are actually pointer vars.
Also convert from regex to normal code, so we can enable this
plugin all the time.
Change-Id: Ie36a25ecba61c18f99c77c77646d6459a443cbd1
Reviewed-on: https://gerrit.libreoffice.org/24391
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
We want a pre-spun-up, shared thread-pool that doesn't get its
workers created & joined frequently.
Change-Id: I29081e3a3e3849ca30e63fd080ee3315d99cbe8d
