Re: [PATCH v2 08/10] vz: remove vzDriverLock/Unlock function

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

 




On 07.04.2016 23:10, Maxim Nestratov wrote:
> We don't need them anymore as all pointers within vzDriver structure
> are not changed during the time it exists.
> Where we still need to synchronize we use virObjectLock/Unlock as far
> as vzDriver is lockable object.
> 
> Signed-off-by: Maxim Nestratov <mnestratov@xxxxxxxxxxxxx>
> ---
>  src/vz/vz_driver.c | 35 -----------------------------------
>  src/vz/vz_utils.h  |  2 --
>  2 files changed, 37 deletions(-)
> 
> diff --git a/src/vz/vz_driver.c b/src/vz/vz_driver.c
> index dce7a87..50da2fe 100644
> --- a/src/vz/vz_driver.c
> +++ b/src/vz/vz_driver.c

...

> @@ -1537,7 +1506,6 @@ vzConnectRegisterCloseCallback(virConnectPtr conn,
>      vzConnPtr privconn = conn->privateData;
>      int ret = -1;
>  
> -    vzDriverLock(privconn);
>      if (virConnectCloseCallbackDataGetCallback(privconn->closeCallback) != NULL) {
>          virReportError(VIR_ERR_OPERATION_INVALID, "%s",
>                         _("A close callback is already registered"));
> @@ -1549,7 +1517,6 @@ vzConnectRegisterCloseCallback(virConnectPtr conn,
>      ret = 0;
>  
>   cleanup:
> -    vzDriverUnlock(privconn);
>  
>      return ret;
>  }
> @@ -1560,7 +1527,6 @@ vzConnectUnregisterCloseCallback(virConnectPtr conn, virConnectCloseFunc cb)
>      vzConnPtr privconn = conn->privateData;
>      int ret = -1;
>  
> -    vzDriverLock(privconn);
>  
>      if (virConnectCloseCallbackDataGetCallback(privconn->closeCallback) != cb) {
>          virReportError(VIR_ERR_OPERATION_INVALID, "%s",
> @@ -1572,7 +1538,6 @@ vzConnectUnregisterCloseCallback(virConnectPtr conn, virConnectCloseFunc cb)
>      ret = 0;
>  
>   cleanup:
> -    vzDriverUnlock(privconn);
>  
>      return ret;
>  }

In this two particular functions we still need locking. The problem is that
close connect object API is not complete self-locking. We need to use
higher level lock because the check that register is possible and register
itself are not atomic. This was made intentionally to make register
function result type be void so that remote driver could be written
transactionally. On ther other hand we can not be client side driver
anymore and our only user is remote driver/daemon pair which is 
considered correct. So it's up to you.

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[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]