[libvirt] PATCH: 0/28: Thread safety for libvirtd daemon and drivers

Ben Guthro bguthro at virtualiron.com
Mon Dec 1 16:07:47 UTC 2008

What git changeset does this queue apply against?

I'm having a heck of a time getting it to apply cleanly with git-am.

I know you work on occasion with mercurial. Is this an mq tree somewhere?

Daniel P. Berrange wrote on 11/30/2008 06:14 PM:
> The following huge series of patches adds thread safety for the libvirtd
> daemon and drivers, and makes the daemon multi-threaded in processing
> RPC calls. This enables multiple clients to be processed in parallel, 
> without blocking each other. It does not change the thread rules for the
> virConnectPtr object though, so each individual client is still serialized.
> There are two core places where we have to have synchronization in the
> threading model this patch series introduces
>  - The libvirt daemon code 
>        - A single global server lock (aka struct qemud_server)
>        - One lock per client connection  (aka struct qemud_client)
>  - The driver implementations
>        - One lock per driver (aka QEMU, LXC, Test, UML, OpenVZ, Network,
>          Storage, Node Devices)
>        - One lock per primary object in a driver (virDomainObjPtr,
>          virNetworkObjPtr, virStoragePoolObjPtr, virNodeDeviceObjptr
>          instances)
> For most cases, the big global server / driver locks are only held while
> obtaining one of the finer grained locks. This gives a fairly good level
> of concurrency for operations touching different objects. Once this core
> infrastructure is merged, it will be possible to iterate on impl of
> drivers to reduce the time locks are held - eg avoid holding a lock while
> talking to the QEMU monitor interface.
> To try and make it easier to spot thread locking problems this series
> refactors alot of methods so that there is only a single return point
> where the unlock call can be placed, rather than multiple return point
> which increases the chances of missing an unlock call.
> This touches a huge amount of code, so I'd like to get this all merged 
> ASAP as it'll be really hard to keep it synced with ongoing changes.
> Daniel

More information about the libvir-list mailing list