On Fri, Apr 17, 2009 at 12:33:30PM -0400, Cole Robinson wrote: > On 04/16/2009 12:24 PM, Daniel P. Berrange wrote: > > On Thu, Apr 16, 2009 at 03:57:52PM +0200, Daniel Veillard wrote: > >> since buildvoldef->building is a condition, maybe it's safer to (un)set > >> it while the lock is taken. > > > > This bit doesn't entirely make sense to me. > > > > The 'buildvoldef' object here is a copy of the real volume defintion > > that only this thread is using. Anyone else polling on virStorageVolGetInfo > > will be accessing th real def and thus not see the fact that you changed > > thee 'building' flag. > > > > I'm thinking you instead meant to set 'voldef->building', and setting > > that flag should be protected by the pool lock as DV mentions. Would > > also need to remove the 'voldef= NULL' line if we're going to set the > > flag on it > > > > Okay, attached patch sets the flag on the original volume definition, > and makes sure we have the pool lock when we do so. This should address > the above (and DV's) comments. This patch looks fine to me now, so ACK for the set of 3 patches, 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