qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC v4 09/21] blockjobs: add CONCLUDED state


From: John Snow
Subject: Re: [Qemu-devel] [RFC v4 09/21] blockjobs: add CONCLUDED state
Date: Wed, 28 Feb 2018 14:29:08 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0


On 02/28/2018 10:37 AM, Kevin Wolf wrote:
> Am 24.02.2018 um 00:51 hat John Snow geschrieben:
>> add a new state "CONCLUDED" that identifies a job that has ceased all
>> operations. The wording was chosen to avoid any phrasing that might
>> imply success, error, or cancellation. The task has simply ceased all
>> operation and can never again perform any work.
>>
>> ("finished", "done", and "completed" might all imply success.)
>>
>> Transitions:
>> Running  -> Concluded: normal completion
>> Ready    -> Concluded: normal completion
>> Aborting -> Concluded: error and cancellations
>>
>> Verbs:
>> None as of this commit. (a future commit adds 'dismiss')
>>
>>              +---------+
>>              |UNDEFINED|
>>              +--+------+
>>                 |
>>              +--v----+
>>              |CREATED|
>>              +--+----+
>>                 |
>>              +--v----+     +------+
>>    +---------+RUNNING<----->PAUSED|
>>    |         +--+-+--+     +------+
>>    |            | |
>>    |            | +------------------+
>>    |            |                    |
>>    |         +--v--+       +-------+ |
>>    +---------+READY<------->STANDBY| |
>>    |         +--+--+       +-------+ |
>>    |            |                    |
>> +--v-----+   +--v------+             |
>> |ABORTING+--->CONCLUDED<-------------+
>> +--------+   +---------+
>>
>> Signed-off-by: John Snow <address@hidden>
> 
>> +static void block_job_event_concluded(BlockJob *job)
>> +{
>> +    if (block_job_is_internal(job) || !job->manual) {
>> +        return;
>> +    }
>> +    block_job_state_transition(job, BLOCK_JOB_STATUS_CONCLUDED);
>> +}
> 
> I don't understand why internal or automatic jobs should follow a
> different state machine. Sure, they won't be in this state for long

The very simple answer is because I overlooked this change from when I
did implement separate graphs for the old and new models.

> because the job is immediately unref'ed. Though if someone holds an
> additional reference, it might be visible - I would consider this a bug
> fix because otherwise the job stays in READY and continues to accept the
> verbs for that state.
> 
> Kevin
> 



reply via email to

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