[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Qemu-devel] [RFC v4 18/21] blockjobs: add block-job-fi
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-block] [Qemu-devel] [RFC v4 18/21] blockjobs: add block-job-finalize |
Date: |
Thu, 1 Mar 2018 11:01:34 +0100 |
User-agent: |
Mutt/1.9.1 (2017-09-22) |
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
- Re: [Qemu-block] [Qemu-devel] [RFC v4 18/21] blockjobs: add block-job-finalize,
Kevin Wolf <=