Re: [Qemu-devel] [RFC v4 16/21] blockjobs: add waiting status

[Kevin Wolf]

Am 27.02.2018 um 21:50 hat John Snow geschrieben:
> 
> 
> On 02/27/2018 03:00 PM, Eric Blake wrote:
> > On 02/23/2018 05:51 PM, John Snow wrote:
> >> For jobs that are stuck waiting on others in a transaction, it would
> >> be nice to know that they are no longer "running" in that sense, but
> >> instead are waiting on other jobs in the transaction.
> >>
> >> Jobs that are "waiting" in this sense cannot be meaningfully altered
> >> any longer as they have left their running loop. The only meaningful
> >> user verb for jobs in this state is "cancel," which will cancel the
> >> whole transaction, too.
> >>
> >> Transitions:
> >> Running -> Waiting:   Normal transition.
> >> Ready   -> Waiting:   Normal transition.
> >> Waiting -> Aborting:  Transactional cancellation.
> >> Waiting -> Concluded: Normal transition.
> >>
> >> Removed Transitions:
> >> Running -> Concluded: Jobs must go to WAITING first.
> >> Ready   -> Concluded: Jobs must go to WAITING fisrt.
> > 
> > s/fisrt/first/
> > 
> >> +++ b/blockjob.c
> > 
> >> @@ -3934,6 +3938,29 @@
> >>               'offset': 'int',
> >>               'speed' : 'int' } }
> >>   +##
> >> +# @BLOCK_JOB_WAITING:
> >> +#
> >> +# Emitted when a block job that is part of a transction has stopped
> >> work and is
> > 
> > s/transction/transaction/
> > 
> >> +# waiting for other jobs in the transaction to reach the same state.
> > 
> > Is this event emitted only for 'new-style' transactions (old drivers
> > will never see it, because they don't request new style), or always (old
> > drivers will see, but presumably ignore, it)?
> > 
> 
> ...! Actually, I meant to remove the WAITING *event* entirely, this is a
> mistake.
> 
> It's purely an informational state that clients likely cannot make any
> real use of, because regardless of old or new style, jobs will
> transition automatically to "PENDING."
> 
> That said, old or new, the state is visible from query-block-jobs.

It means that the block job isn't working any more, which could possibly
be useful information.

Umm... When mirror transitions into WAITING, it stops working, but
doesn't change the graph yet. Isn't that a problem? Currently it doesn't
cause bugs because mirror doesn't support transactions, but we should
design things so that mirror could become transactionable later on.

I suppose one way to achieve this would be that mirror only transitions
into WAITING when the whole transaction is ready to move forward. In
this case, block-job-complete wouldn't tell mirror any more to actually
complete, but just to signal that the user is ready to have this job
completed.

Essentially this would split READY in two: The first state is when the
job has completed the bulk job and waits for the user, and the second
state is after the user sent block-job-complete. The second state
automatically transitions into WAITING as soon as all other jobs in the
transaction are either WAITING or in the second READY state.

Alternatively, mirror jobs could stay active in the WAITING phase, which
would then become the second READY phase. In this case, the state
machine would stay as it is, just the semantics of WAITING would change.

The result is either way that the WAITING event becomes uninteresting,
so after all I think I agree with completely removing it.

Kevin