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(a)veillard.com | Rpmfind RPM search engine
http://rpmfind.net/
http://veillard.com/ | virtualization library
http://libvirt.org/