On Wed, Nov 23, 2011 at 09:04:50AM -0700, Eric Blake wrote: > On 11/23/2011 07:48 AM, Stefan Hajnoczi wrote: > > This means that virDomainBlockJobAbort() returns to the client without > > a guarantee that the job has completed. If the client enumerates jobs > > it may still see a job that has not finished cancelling. The client > > must register a handler for the BLOCK_JOB_CANCELLED event if it wants > > to know when the job really goes away. The BLOCK_JOB_CANCELLED event > > has the same fields as the BLOCK_JOB_COMPLETED event, except it lacks > > the optional "error" message field. > > > > The impact on clients is that they need to add a BLOCK_JOB_CANCELLED > > handler if they really want to wait. Most clients today (not many > > exist) will be fine without waiting for cancellation. > > > > Any objections or thoughts on this? > > virDomainBlockJobAbort() thankfully has an 'unsigned int flags' > argument. For backwards-compatibility, I suggest we use it: > > calling virDomainBlockJobAbort(,0) maintains old blocking behavior, and > we document that blocking until things abort may render the rest of > interactions with the domain unresponsive. > > The new virDomainBlockJobAbort(,VIR_DOMAIN_BLOCK_JOB_ABORT_ASYNC) would > then implement your new proposed semantics of returning immediately once > the cancellation has been requested, even if it hasn't been acted on yet. > > Maybe you could convince me to swap the flags: have 0 change semantics > to non-blocking, and a new flag to request blocking, where callers that > care have to try the flag, and if the flag is unsupported then they know > they are talking to older libvirtd where the behavior is blocking by > default, but that's a bit riskier. Agreed, I would rather not change the current call semantic, but an ASYNC flag would be a really good addition. We can document the risk of not using it in the function description and suggest new applications use ASYNC flag. 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