qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 06/45] block: add support for job pause/resum


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH v2 06/45] block: add support for job pause/resume
Date: Thu, 27 Sep 2012 15:51:15 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0

Am 27.09.2012 14:57, schrieb Paolo Bonzini:
> Il 27/09/2012 14:45, Kevin Wolf ha scritto:
>> Am 27.09.2012 14:27, schrieb Paolo Bonzini:
>>> Il 27/09/2012 14:18, Kevin Wolf ha scritto:
>>>>>>
>>>>>> Signed-off-by: Paolo Bonzini <address@hidden>
>>>> I think there's a problem with terminology at least. What does "paused"
>>>> really mean? Is it that the job has been requested to pause, or that it
>>>> has actually yielded and is inactive?
>>>>
>>>> The commit message seems to use the latter semantics (which I would
>>>> consider the intuitive one),
>>>
>>> You mean this: "Paused jobs cannot be canceled without first resuming
>>> them".  I can add a specification, like "(even if the job actually has
>>> not reached the sleeping point and thus is still running)".
>>
>> I actually meant "pause happens at the next sleeping point", which isn't
>> unspecific at all.
> 
> Hmm, there are two aspects: 1) when things stop running; 2) when the job
> reports itself to be paused.  The commit message describes (1)
> precisely, and doesn't say anything about (2).  That's too specific for
> a commit message, but the header file describes it precisely.

Yes, I understood that, I just found it confusing that both were called
"paused" in different contexts.

> However, in the QMP documentation, the good comment for "bool paused;"
> must be replicated in BlockJobInfo's "paused" member.
> 
>>> From the QMP client's point of view it doesn't really matter, does it?
>>>
>>> - even after a job that writes to disk X has "really" paused, you cannot
>>> read or write disk X.  It's still owned by QEMU, it hasn't been flushed,
>>> it may play games like lazy refcounts.
>>
>> I'm not sure about this one. Consider things like a built-in NBD server.
>> Probably we'll find more cases in the future, where some monitor command
>> might seem to be safe while a job is paused.
> 
> Ok, that's a good point.  I'll add a "busy" member to BlockJobInfo.

Ok, thanks. Together with the comment from the bool paused field this
should make pretty clear what clients would have to check for.

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]