From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42370) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RTFJu-0006WU-FY for qemu-devel@nongnu.org; Wed, 23 Nov 2011 11:05:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RTFJk-00084b-KW for qemu-devel@nongnu.org; Wed, 23 Nov 2011 11:05:10 -0500 Received: from mx1.redhat.com ([209.132.183.28]:28916) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RTFJk-00084O-8n for qemu-devel@nongnu.org; Wed, 23 Nov 2011 11:05:00 -0500 Message-ID: <4ECD19A2.4010501@redhat.com> Date: Wed, 23 Nov 2011 09:04:50 -0700 From: Eric Blake MIME-Version: 1.0 References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigC5A5255B79D61DD19C5B6625" Subject: Re: [Qemu-devel] [libvirt] virDomainBlockJobAbort and block_job_cancel List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: libvir-list@redhat.com, Anthony Liguori , qemu-devel This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC5A5255B79D61DD19C5B6625 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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. >=20 > 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. >=20 > 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. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enigC5A5255B79D61DD19C5B6625 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJOzRmjAAoJEKeha0olJ0NqSjcH+QFmrx8A5uB/dy7LyOiO+7PU 7wnWV0mEw4rXyVFjN4XrdC96hocyUB7heevLa4ub8ur1DM05tZb/txswN7RVUEoO ubrzX/BvQmquz8LfzQcE1aJA22ji3d8KyEfl5/Ww/MV/ZyNv00tdz6Ps2E91j1I+ q+DKarMMDbBH+Wl/PBH6MK4Ti2wI1o/3hBeiTePmHVaO29DIhk2YprfHSwfV9U6+ T6wwRpXZQNDae3Jzh4UD7FvLuzaHgk8iI9bTUFu0NLuI0xb/q+TmdHH6AW+Szl5h 8YUXwTuZyjiLUeTykepBzmd0R6uBPzpOb3CiafuqwSgH39q4LyFaspyrRiRQChs= =QJ3I -----END PGP SIGNATURE----- --------------enigC5A5255B79D61DD19C5B6625--