On Wed, Apr 15, 2009 at 03:26:44PM -0400, Cole Robinson wrote: > Implement non-pool-blocking volume allocation for FS volumes. > > We setup the volume object, then drop the pool lock, and start the > actual storage allocation. Certain pool operations will be blocked > (start, stop, destroy, refresh), but the basic things like volume > listings will still work. > > This also allows storage allocation progress reporting: the API user can > watch the volume object in a separate thread, polling it's 'info' for > update to date capacity/allocation reporting. Okay, that one is far more complex :-) [...] > + /* Make a shallow copy of the 'defined' volume definition, since the > + * original allocation value will change as the user polls 'info', > + * but we only need the initial requested values > + */ > + memcpy(buildvoldef, voldef, sizeof(*voldef)); > + voldef = NULL; > + > + /* Drop the pool lock during volume allocation */ > + pool->asyncjobs++; > + virStoragePoolObjUnlock(pool); > + > + buildvoldef->building = 1; > + buildret = backend->buildVol(obj->conn, buildvoldef); > + buildvoldef->building = 0; > + > + virStoragePoolObjLock(pool); > + pool->asyncjobs--; since buildvoldef->building is a condition, maybe it's safer to (un)set it while the lock is taken. I think the scheme works, but one thing we need to be careful about if that if adding new operations they should also look at that ->building condition. 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