[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
Re: [Qemu-block] [Qemu-devel] [RFC v4 18/21] blockjobs: add block-job-finalize
Thu, 1 Mar 2018 14:24:19 -0500
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
On 03/01/2018 05:01 AM, Kevin Wolf wrote:
> 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
>> 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
No, that's a good point. I'll go with the simpler implementation, but
I'll leave a mention of the other approach in the RFC and we'll see if
there are other comments.
At some point I'll need to prod Pkrempa and make sure the design looks
tenable to him, too.