Since threadpool increments the current number of threads according to current
load, i.e. how many jobs are waiting in the queue. The count however, is
constrained by max and min limits of workers. The logic of this new API works
like this:
1) setting the minimum
a) When the limit is increased, depending on the current number of
threads, new threads are possibly spawned if the current number of
threads is less than the new minimum limit
b) Decreasing the minimum limit has no possible effect on the current
number of threads
2) setting the maximum
a) Icreasing the maximum limit has no immediate effect on the current
number of threads, it only allows the threadpool to spawn more
threads when new jobs, that would otherwise end up queued, arrive.
b) Decreasing the maximum limit may affect the current number of
threads, if the current number of threads is less than the new
maximum limit. Since there may be some ongoing time-consuming jobs
that would effectively block this API from killing any threads.
Therefore, this API is asynchronous with best-effort execution,
i.e. the necessary number of workers will be terminated once they
finish their previous job, unless other workers had already
terminated, decreasing the limit to the requested value.
3) setting priority workers
- both increase and decrease in count of these workers have an
immediate impact on the current number of workers, new ones will be
spawned or some of them get terminated respectively.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
In order for the client to see all thread counts and limits, current total
and free worker count getters need to be introduced. Client might also be
interested in the job queue length, so provide a getter for that too. As with
the other getters, preparing for the admin interface, mutual exclusion is used
within all getters.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
So far, the values the affected getters retrieve are static, i.e. there's no
way of changing them during runtime. But admin interface will later enable
not only getting but changing them as well. So to prevent phenomenons like
torn reads or concurrent reads and writes of unaligned values, use mutual
exclusion when getting these values (writes do, understandably, use them
already).
Signed-off-by: Erik Skultety <eskultet@redhat.com>
When either creating a threadpool, or creating a new thread to accomplish a job
that had been placed into the jobqueue, every time thread-specific data need to
be allocated, threadpool needs to be (re)-allocated and thread count indicators
updated. Make the code clearer to read by compressing these operations into a
more complex one.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Using joinable threads does not help anything, but it can lead to memory
leaks.
When a worker thread exits, it decreases nWorkers or nPrioWorkers and
once both nWorkers and nPrioWorkers are zero (i.e., the last worker is
gone), quit_cond is signaled. When freeing the pool we first tell all
threads to die and then we are waiting for both nWorkers and
nPrioWorkers to become zero. At this point we already know all threads
are gone. So the only reason for calling virThreadJoin of all workers is
to free the memory allocated for joinable threads. If we avoid
allocating this memory, we don't need to take care of freeing it.
Moreover, any memory associated with a worker thread which died before
we asked it to die (e.g., because virCondWait failed in the thread)
would be lost anyway since virThreadPoolFree calls virThreadJoin only
for threads which were running at the time virThreadPoolFree was called.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Every thread created as a worker thread within a pool gets a name
according to virThreadPoolJobFunc name.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Commit a1cbe4b5 added a check for spaces around assignments and this
patch extends it to checks for spaces around '=='. One exception is
virAssertCmpInt where comma after '==' is acceptable (since it is a
macro and '==' is its argument).
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
In 78839da I am trying to join the worker threads. However, I can't
sipmly reuse pool->nWorkers (same applies for pool->nPrioWorkers),
because of the following flow that is currently implemented:
1) the main thread executing virThreadPoolFree sets pool->quit = true,
wakes up all the workers and wait on pool->quit_cond.
2) A worker is woken up and see quit request. It immediately jumps of
the while() loop and decrements pool->nWorkers (or pool->nPrioWorkers in
case of priority worker). The last thread signalizes pool->quit_cond.
3) Main thread is woken up, with both pool->nWorkers and
pool->nPrioWorkers being zero.
So there's a need to copy the original value of worker thread counts
into local variables. However, these need to set *after* the check for
pool being NULL (dereferencing a NULL is no no). And for safety they can
be set right after the pool is locked.
Reported-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Even though currently we are freeing the pool of worker threads at the
daemon very end, nothing holds us back in joining the worker threads.
Moreover, we avoid leaks like this:
==26697== 1,680 bytes in 5 blocks are possibly lost in loss record 913 of 942
==26697== at 0x4C2BDE4: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26697== by 0x4011131: allocate_dtv (in /lib64/ld-2.16.so)
==26697== by 0x401176D: _dl_allocate_tls (in /lib64/ld-2.16.so)
==26697== by 0x8499602: pthread_create@@GLIBC_2.2.5 (in /lib64/libpthread-2.16.so)
==26697== by 0x52F53E9: virThreadCreate (virthreadpthread.c:188)
==26697== by 0x52F5D4F: virThreadPoolNew (virthreadpool.c:221)
==26697== by 0x53F30DB: virNetServerNew (virnetserver.c:377)
==26697== by 0x11C6ED: main (libvirtd.c:1366)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
