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 <[email protected]>
>
>> +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
>
