[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.
alternately:
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