From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41124) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1erL25-0001Lv-LB for qemu-devel@nongnu.org; Thu, 01 Mar 2018 05:01:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1erL1z-0001DU-Ro for qemu-devel@nongnu.org; Thu, 01 Mar 2018 05:01:49 -0500 Date: Thu, 1 Mar 2018 11:01:34 +0100 From: Kevin Wolf Message-ID: <20180301100134.GB4862@localhost.localdomain> References: <20180223235142.21501-1-jsnow@redhat.com> <20180223235142.21501-19-jsnow@redhat.com> <20180228181553.GL4855@localhost.localdomain> <24618453-fd43-de12-1e14-2fc9ed2c4b8b@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24618453-fd43-de12-1e14-2fc9ed2c4b8b@redhat.com> Subject: Re: [Qemu-devel] [RFC v4 18/21] blockjobs: add block-job-finalize List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Snow Cc: pkrempa@redhat.com, jtc@redhat.com, qemu-devel@nongnu.org, qemu-block@nongnu.org Am 28.02.2018 um 20:14 hat John Snow geschrieben: > > > On 02/28/2018 01:15 PM, Kevin Wolf wrote: > > Is it because you want to avoid that the user picks an automatic job for > > completing the mixed transaction? > > I wanted to avoid the case that a job without the manual property would > be stuck "pending" -- which I have defined to mean that it is waiting on > an authorization from the user -- which isn't really true: it's waiting > on its peers in the transaction to receive that authorization. > > It would indeed be simpler to just let them stick around in PENDING like > their peers, but it felt like a hacky way to allow mixed-mode > transactions -- like they had been promoted for just a subset of their > lifetime. > > So, mostly it was a semantic decision and not a functional one based on > what I considered "WAITING" to mean vs "PENDING". > > If the definitions (and documentation) are adjusted it can be changed > for the simpler layout if it seems just as good from the API > perspective. (It's certainly better implementationally, as you say.) I actually like it better conceptually, too, because I think of WAITING as a state that waits for jobs in earlier states (i.e. RUNNING/READY usually) and then everything moves forward together. Also waiting for jobs that are already in a later state like PENDING, but only for automatic jobs, makes the mental model more complex (or maybe it's just me...). Kevin