From: Daniel Veillard <veillard@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: libvir-list@redhat.com, Stefan Hajnoczi <stefanha@gmail.com>,
Anthony Liguori <aliguori@us.ibm.com>,
qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [libvirt] virDomainBlockJobAbort and block_job_cancel
Date: Thu, 24 Nov 2011 13:31:12 +0800 [thread overview]
Message-ID: <20111124053112.GV11916@redhat.com> (raw)
In-Reply-To: <4ECD19A2.4010501@redhat.com>
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/
next prev parent reply other threads:[~2011-11-24 5:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-23 14:48 [Qemu-devel] virDomainBlockJobAbort and block_job_cancel Stefan Hajnoczi
2011-11-23 16:04 ` [Qemu-devel] [libvirt] " Eric Blake
2011-11-24 5:31 ` Daniel Veillard [this message]
2011-11-24 9:21 ` Stefan Hajnoczi
2011-12-07 22:35 ` Adam Litke
2011-12-07 23:01 ` Eric Blake
2011-12-08 14:55 ` Stefan Hajnoczi
2011-12-08 14:55 ` Adam Litke
2011-12-08 15:33 ` Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111124053112.GV11916@redhat.com \
--to=veillard@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=eblake@redhat.com \
--cc=libvir-list@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.