From pthread_cond_wait()'s man page:
When using condition variables there is always a boolean predicate involving
shared variables associated with each condition wait that is true if the
thread should proceed. Spurious wakeups from the pthread_cond_wait() or
pthread_cond_timedwait() functions may occur. Since the return from
pthread_cond_wait() or pthread_cond_timedwait() does not imply anything about
the value of this predicate, the predicate should be re-evaluated upon such
return.
Fix ~CThreadPool() to account for this possibility.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When a job was cancelled after its runThread() method finished, but before the
main thread noticed this and reacted, we would just run runMain() before and
pretend the job finished normally.
However, with CModuleJob this means that runMain() might get called for a module
which is currently being destructed. This has bad effects with virtual functions
and thus causes problems. It's better to just really cancel the job instead.
Signed-off-by: Uli Schlachter <psychon@znc.in>
There was a race where threads were themselves responsible for increasing the
counter for the number of running threads. This left an open window where the
thread was already started, but our counter was not yet increased. The effect of
this race would be that we start more threads than we should.
Fix this by increasing the counter before actually starting new worker threads.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This adds CThreadPool::cancelJob() and cancelJobs() which can cancel a set of
jobs synchronously. These functions only return when the job was successfully
cancelled.
It tries to cancel the jobs as quickly as possible, skipping any callbacks on
CJob that were not yet called. A job that is already running can use
CJob::wasCancelled() to check if it should quit.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The following people agreed with the change, in alphabetical order:
(people who approved in several ways are listed only once)
By email:
- Adam (from Anope)
- Austin Morton
- Brian Campbell
- Christian Walde
- Daniel Holbert
- Daniel Wallace
- Falk Seidel
- Heiko Hund
- Ingmar Runge
- Jim Hull
- Kyle Fuller
- Lee Aylward
- Martin Martimeo
- Matt Harper
- Michael J Edgar
- Michael Ziegler
- Nick Bebout
- Paul Driver
- Perry Nguyen
- Philippe (cycomate)
- Reuben Morais
- Roland Hieber
- Sebastian Ramacher
- Stefan Rado
- Stéphan Kochen
- Thomas Ward
- Toon Schoenmakers
- Veit Wahlich
- Wulf C. Krueger
By IRC:
- CNU
- Jonas Gorski
- Joshua M. Clulow
- Prozac/SHiZNO
- SilverLeo
- Uli Schlachter
At https://github.com/znc/znc/issues/311 :
- Alexey Sokolov
- Elizabeth Myers
- flakes
- Jens-Andre Koch
- Jyzee
- KindOne/ineedalifetoday
- Lee Williams
- Mantas Mikulėnas
- md-5
- Reed Loden
At the last few pull requests' comments:
- Allan Odgaard
- Jacob Baines
- Lluís Batlle i Rossell
- ravomavain
- protomouse
The following commits' authors didn't respond:
Trivial changes:
- f70f1086fd
- 4ca8b50e45
The changes which are not presented in master anymore:
- 5512ed2ea0
- 960a4498f7
- 0f739de2c0
- 7f53cc810bFix#311Fix#218
This just moves the pipe from the socket code to the thread pool. However, now
all CJobs can use this and there is a single place for them to get deleted.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This should make it easier to work with threads. It provides classes for mutexes
and condition variables. Additionally, there is a special CMutexGuard that
automatically unlocks the mutex on destruction and a CThreadPool class.
This thread pool is used to replace the thread pool in the sockets code.
Signed-off-by: Uli Schlachter <psychon@znc.in>
