Re: [libvirt PATCH 01/11] virthreadpool: Use automatic memory management

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2/7/22 14:12, Tim Wiederhake wrote:
> Signed-off-by: Tim Wiederhake <twiederh@xxxxxxxxxx>

s/memory/lock/ in $SUBJ.

> ---
>  src/util/virthreadpool.c | 39 +++++++++++++--------------------------
>  1 file changed, 13 insertions(+), 26 deletions(-)
> 
> diff --git a/src/util/virthreadpool.c b/src/util/virthreadpool.c
> index 426840e435..b6d154802a 100644
> --- a/src/util/virthreadpool.c
> +++ b/src/util/virthreadpool.c
> @@ -306,15 +306,13 @@ void virThreadPoolFree(virThreadPool *pool)
>      if (!pool)
>          return;
>  
> -    virMutexLock(&pool->mutex);

Look at this made me realize we need to check pool->quit in
virThreadPoolSetParameters(). I was trying to come up with a path where
removing this lock acquire would create a problem (because removing a
mutex makes all the control lights flash for me), but failed. I'm still
trying to convince myself this is safe thing to do.

On the other hand, if we used automatic mutex management, then ...

> -    virThreadPoolDrainLocked(pool);
> +    virThreadPoolDrain(pool);
>  
>      if (pool->identity)
>          g_object_unref(pool->identity);
>  
>      g_free(pool->jobName);
>      g_free(pool->workers);
> -    virMutexUnlock(&pool->mutex);
>      virMutexDestroy(&pool->mutex);

.. this would destroy a locked mutex. So I guess your code is right.

>      virCondDestroy(&pool->quit_cond);
>      virCondDestroy(&pool->cond);

Michal




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux