On Fri, Oct 23, 2009 at 02:05:32PM +0100, Daniel P. Berrange wrote: > A number of driver API methods which acquire the driver mutex > only ever used the driver object in a read-only fashion. All > these uses are converted to call qemuDriverLockRO() allowing > for greater concurrency. > > * src/qemu/qemu_conf.h: s/Mutex/RWLock/ > * src/qemu/qemu_driver.c: Add a qemuDriverLockRO() method and use > it anywhere that doesn't require a write lock on the driver Hum, I still wonder about erro handling strategies there, for example even taking a read lock may fail not because of a programing error because there is already too many read lock taken. [...] > @@ -6834,6 +6846,8 @@ cleanup: > > if (vm) > virDomainObjUnlock(vm); > + qemuDriverUnlock(driver); > + qemuDriverLock(driver); > if (event) > qemuDomainEventQueue(driver, event); > qemuDriverUnlock(driver); Huh ??? really ? we need a way to allow other threads to get in ? Maybe a tiny wait here would allow a rescheduling especially if on a single processor. But otherwise this looks like a fairly automatic conversion so should go in with 02/21 when ready, ACK Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list