From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48041) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bpaUb-0004MQ-BL for qemu-devel@nongnu.org; Thu, 29 Sep 2016 08:31:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bpaUX-00034V-Ur for qemu-devel@nongnu.org; Thu, 29 Sep 2016 08:31:13 -0400 Date: Thu, 29 Sep 2016 13:30:58 +0100 From: Stefan Hajnoczi Message-ID: <20160929123058.GA5916@stefanha-x1.localdomain> References: <1470683381-16680-1-git-send-email-jsnow@redhat.com> <57E94491.8090501@virtuozzo.com> <57EBB4A1.1000104@virtuozzo.com> <20160929113307.GJ5742@noname.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline In-Reply-To: <20160929113307.GJ5742@noname.redhat.com> Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 0/5] blockjobs: Fix transactional race condition List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Vladimir Sementsov-Ogievskiy , qemu block , qemu-devel , Stefan Hajnoczi , "Denis V. Lunev" --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 29, 2016 at 01:33:07PM +0200, Kevin Wolf wrote: > Am 28.09.2016 um 14:16 hat Vladimir Sementsov-Ogievskiy geschrieben: > > >I think jobs will need to remain "one coroutine, one job" for now, > > >but there's no reason why drive-backup or blockdev-backup can't > > >just create multiple jobs each if that's what they need to do. > > >(The backup job object could, in theory, just have another job > > >pointer to a helper job if it really became necessary.) >=20 > What's the problem with a job spawning additional coroutines internally? > Jobs already do this all the time (AIO requests are just coroutines in > disguise.) >=20 > A job is basically just the user interface for managing a background > process, so helper jobs that are managed internally rather than by the > user don't seem to make that much sense. Internal blockjobs do have use cases. The COLO replication code uses them and that's good because it avoids code duplication. While internal blockjob users don't need to be hooked up to the QMP monitor, they might want other aspects like rate-limiting, pause/resume, ready/complete lifecycle, etc which are implemented in blockjob.c and not part of plain old coroutines. A layering model that supports this is: 1. User-initiated blockjobs, exposed via QMP 2. Blockjob core API 3. mirror, commit, etc It should be possible for internal users like COLO replication to talk to blockjob core. That way the functionality mentioned above is available. If there is a valid reason for a blockjob to be composed of other block jobs, then it could be done properly with this layering model. I don't know if there are valid use cases for this though ;). Stefan --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJX7QmCAAoJEJykq7OBq3PIN8EH/2xhnwfSKj3dbCimNX4TU9b/ /vRVXcx+BsMNRSjrZyFPAMIfqN7j3b31wS8I16U3ANrw18eUverLxqOAjhCusgql sb8mqjjCqbRwLVjiHbCH8+6zOY0m/TqTstCxk1o1kvpg6UHZaQyYUL5u+eI0TZDA HMBQwRRRjip1V8xUEaJhl7vECuyw7R/qWbyj+NDrJUGn/+9DnlVmNIbzZodiasrj Y1ps7eaKfYVe7cNd3KVUpbrjsXckA5f6sTwxDfD4GhxiP7pjpYKb6wA+HBTm1frU m/IS6OzE19bBF0K/oxKa270N63zFogysBHCWHe2NLBGaT+dbqX4BQaIR+fCbc64= =ehii -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4--