On Tue, Jan 20, 2009 at 10:21:44AM +0000, Daniel P. Berrange wrote: > On Tue, Jan 20, 2009 at 08:17:07AM +0100, Guido G?nther wrote: > > Hi, > > On Mon, Jan 19, 2009 at 01:38:22PM +0000, Daniel P. Berrange wrote: > > > > /* Got them all, so now open the monitor console */ > > > > - ret = qemudOpenMonitor(conn, vm, monitor); > > > > + qemuDriverLock(driver); > > > > + ret = qemudOpenMonitor(conn, driver, vm, monitor, 0); > > > > + qemuDriverUnlock(driver); > > > > > > What are the lock/unlock calls here for ? They will cause the whole > > > driver to deadlock, because they're violating the rule that a domain > > > lock must not be held while acquiring the driver lock. AFAICT in the > > > qemudOpenMonitor() method you are just passing the 'driver' object > > > straight through to the 'virEventAddHandle' method - since you are > > > not using any data fields in it, locking is not required. > > I looked at HACKING and couldn't find any explanation of the locking > > rules so I added those. They're bogus. Dropped in the new attached > > version. > > Yes, I need to write a doc about threading - its too long to put into > the HACKING file directly. > > > ACK, this looks good now. Okay commited for Guido, 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