From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57821) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RTRuF-0003w5-RS for qemu-devel@nongnu.org; Thu, 24 Nov 2011 00:31:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RTRuE-0002Yg-Lc for qemu-devel@nongnu.org; Thu, 24 Nov 2011 00:31:31 -0500 Received: from mx1.redhat.com ([209.132.183.28]:8799) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RTRuE-0002YR-Ec for qemu-devel@nongnu.org; Thu, 24 Nov 2011 00:31:30 -0500 Date: Thu, 24 Nov 2011 13:31:12 +0800 From: Daniel Veillard Message-ID: <20111124053112.GV11916@redhat.com> References: <4ECD19A2.4010501@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ECD19A2.4010501@redhat.com> Subject: Re: [Qemu-devel] [libvirt] virDomainBlockJobAbort and block_job_cancel Reply-To: veillard@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: libvir-list@redhat.com, Stefan Hajnoczi , Anthony Liguori , qemu-devel 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@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/