Re: [libvirt] PATCH: 2 of 5: Remove virDomainObjPtr linked list
On Mon, Oct 06, 2008 at 04:45:13PM +0200, Daniel Veillard wrote:
On Fri, Oct 03, 2008 at 01:25:17PM +0100, Daniel P. Berrange wrote:
> This patch removes the linked list in the virDomainObjPtr object, and
> adds a new virDomainObjList struct to track domains as an array. The
> QEMU, LXC, OpenVZ and Test drivers get updated to account for this API
> change.
Hum, the only danger I see is that then you can't garantee the
virDomainObjPtr value for parallel access as the (semi-frequent)
realloc is likely to change them. You then need to take the global
lock before trying to access this structure and never cache its value.
I guess that's fine though considering the expected usage.
Yes, you can. The list doesn't store the objects themselves, only
the pointers to the objects. So, once you have a locked object
instance, you can re-alloc the list at will and it won't be change
the object.
I'll have a proof of concept for the QEMU driver demoing this soon,
but the general rule will be thus:
To use an existing domain object
- lock the driver
- find the virDomainObjPtr you need and lock it
- unlock the driver
- do work with the virDomainObjPtr
- ulock the virDomainObjPtr
To add a new domain object
- lock the driver
- create the virDomainObjPtr and lock it
- unlock the driver
- start the VM / save the config
- unlock the virDomainObjPtr
To delete a domain object
- lock the driver
- find the virDomainObjPtr you need and lock it
- ulock the virDomainObjPtr
- delete the virDomainObjPtr
- unlock the driver
NB, the lock + immediate unlock of the virDomainObjPtr ensures that
no other thread still holds a refernce to the object we're about
to delete, and they can't re-acquire one until we unlock the driver.
That gives reasonably fine grained locking that works for all driver
APIs. In some API calls which can take a long time to complete though,
we need to unlock & relock the virDomainObjPtr several times around
long running APIs calls.
But each driver still need to access those structures directly,
with the future goal of having driver loaded as shared lib modules
maybe that interface should be defined as a few entry points to
add, remove, lookup and iterate (with a callback). The refactoring
here might be a good opportunity to hide the implementation from
driver code. Opinion ?
This won't really gain us anything from point of view of thread safety,
and I don't think it magically solves any compatability issues wrt to
loadable drivers.
This is another topic entirely, but when we do have loadable modules,
my feeling is to require that they all be built in-tree, and not allow
(potentially closed-source) out of tree modules. If we mandate that
they're in tree then there's no ABI compatability to worry about.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|