diff options
author | Kevin Wolf <kwolf@redhat.com> | 2018-04-25 15:09:58 +0200 |
---|---|---|
committer | Kevin Wolf <kwolf@redhat.com> | 2018-05-23 14:30:51 +0200 |
commit | df956ae2014340bf7de0190edb1d09be55d9eadf (patch) | |
tree | b9a1cf5b69c78c974f5b697189c7c26dae58def6 /job.c | |
parent | 5f9a6a08e8f65e01746d2485fc65a3a78e74865f (diff) | |
download | qemu-df956ae2014340bf7de0190edb1d09be55d9eadf.zip qemu-df956ae2014340bf7de0190edb1d09be55d9eadf.tar.gz qemu-df956ae2014340bf7de0190edb1d09be55d9eadf.tar.bz2 |
job: Add job_is_ready()
Instead of having a 'bool ready' in BlockJob, add a function that
derives its value from the job status.
At the same time, this fixes the behaviour to match what the QAPI
documentation promises for query-block-job: 'true if the job may be
completed'. When the ready flag was introduced in commit ef6dbf1e46e,
the flag never had to be reset to match the description because after
being ready, the jobs would immediately complete and disappear.
Job transactions and manual job finalisation were introduced only later.
With these changes, jobs may stay around even after having completed
(and they are not ready to be completed a second time), however their
patches forgot to reset the ready flag.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Diffstat (limited to 'job.c')
-rw-r--r-- | job.c | 22 |
1 files changed, 22 insertions, 0 deletions
@@ -199,6 +199,28 @@ bool job_is_cancelled(Job *job) return job->cancelled; } +bool job_is_ready(Job *job) +{ + switch (job->status) { + case JOB_STATUS_UNDEFINED: + case JOB_STATUS_CREATED: + case JOB_STATUS_RUNNING: + case JOB_STATUS_PAUSED: + case JOB_STATUS_WAITING: + case JOB_STATUS_PENDING: + case JOB_STATUS_ABORTING: + case JOB_STATUS_CONCLUDED: + case JOB_STATUS_NULL: + return false; + case JOB_STATUS_READY: + case JOB_STATUS_STANDBY: + return true; + default: + g_assert_not_reached(); + } + return false; +} + bool job_is_completed(Job *job) { switch (job->status) { |