From: Max Reitz <mreitz@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>, qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
famz@redhat.com, Jeff Cody <jcody@redhat.com>,
vsementsov@parallels.com, John Snow <jsnow@redhat.com>
Subject: Re: [Qemu-devel] [RFC 5/9] block: add block job transactions
Date: Wed, 24 Jun 2015 20:37:43 +0200 [thread overview]
Message-ID: <558AF8F7.7010803@redhat.com> (raw)
In-Reply-To: <1434103761-29871-6-git-send-email-stefanha@redhat.com>
On 12.06.2015 12:09, Stefan Hajnoczi wrote:
> Sometimes block jobs must execute as a transaction group. Finishing
> jobs wait until all other jobs are ready to complete successfully.
> Failure or cancellation of one job cancels the other jobs in the group.
>
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> ---
> blockjob.c | 160 ++++++++++++++++++++++++++++++++++++++++++++++
> include/block/block.h | 1 +
> include/block/block_int.h | 3 +-
> include/block/blockjob.h | 49 ++++++++++++++
> trace-events | 4 ++
> 5 files changed, 216 insertions(+), 1 deletion(-)
>
> diff --git a/blockjob.c b/blockjob.c
> index 2755465..ff622f5 100644
> --- a/blockjob.c
> +++ b/blockjob.c
> @@ -399,3 +399,163 @@ void block_job_defer_to_main_loop(BlockJob *job,
>
> qemu_bh_schedule(data->bh);
> }
> +
> +/* Transactional group of block jobs */
> +struct BlockJobTxn {
> + /* Jobs may be in different AioContexts so protect all fields */
> + QemuMutex lock;
> +
> + /* Reference count for txn object */
> + unsigned int ref;
> +
> + /* Is this txn cancelling its jobs? */
> + bool aborting;
> +
> + /* Number of jobs still running */
> + unsigned int jobs_pending;
> +
> + /* List of jobs */
> + QLIST_HEAD(, BlockJob) jobs;
> +};
> +
> +BlockJobTxn *block_job_txn_new(void)
> +{
> + BlockJobTxn *txn = g_new(BlockJobTxn, 1);
> + qemu_mutex_init(&txn->lock);
> + txn->ref = 1; /* dropped by block_job_txn_begin() */
> + txn->aborting = false;
> + txn->jobs_pending = 0;
> + QLIST_INIT(&txn->jobs);
> + return txn;
> +}
> +
> +static void block_job_txn_unref(BlockJobTxn *txn)
> +{
> + qemu_mutex_lock(&txn->lock);
> +
> + if (--txn->ref > 0) {
> + qemu_mutex_unlock(&txn->lock);
> + return;
> + }
> +
> + qemu_mutex_unlock(&txn->lock);
> + qemu_mutex_destroy(&txn->lock);
> + g_free(txn);
> +}
> +
> +/* The purpose of this is to keep txn alive until all jobs have been added */
> +void block_job_txn_begin(BlockJobTxn *txn)
> +{
> + block_job_txn_unref(txn);
> +}
> +
> +void block_job_txn_add_job(BlockJobTxn *txn, BlockJob *job)
> +{
> + if (!txn) {
> + return;
> + }
Do you plan on making use of this case? I'm asking because while I'm
usually in favor of handling everything gracefully as long as it's easy
to implement, here I can't think of a case where using NULL with this
function makes sense, that is to me it would seem like the caller made
some bad mistake. This in turn would mean that dereferencing a NULL
pointer or failing an assertion were preferable to hiding that mistake.
Other than this small thing and that it doesn't compile (until patch 7,
I presume), looks good.
Max
next prev parent reply other threads:[~2015-06-24 18:37 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-12 10:09 [Qemu-devel] [RFC 0/9] block: incremental backup transactions using BlockJobTxn Stefan Hajnoczi
2015-06-12 10:09 ` [Qemu-devel] [RFC 1/9] qapi: Add transaction support to block-dirty-bitmap operations Stefan Hajnoczi
2015-06-12 10:09 ` [Qemu-devel] [RFC 2/9] iotests: add transactional incremental backup test Stefan Hajnoczi
2015-06-12 10:09 ` [Qemu-devel] [RFC 3/9] block: rename BlkTransactionState and BdrvActionOps Stefan Hajnoczi
2015-06-12 10:09 ` [Qemu-devel] [RFC 4/9] block: keep bitmap if incremental backup job is cancelled Stefan Hajnoczi
2015-06-12 22:39 ` John Snow
2015-06-15 14:48 ` Stefan Hajnoczi
2015-06-24 17:35 ` Max Reitz
2015-06-25 12:51 ` Stefan Hajnoczi
2015-06-12 10:09 ` [Qemu-devel] [RFC 5/9] block: add block job transactions Stefan Hajnoczi
2015-06-24 18:37 ` Max Reitz [this message]
2015-06-25 12:50 ` Stefan Hajnoczi
2015-06-12 10:09 ` [Qemu-devel] [RFC 6/9] blockdev: make BlockJobTxn available to qmp 'transaction' Stefan Hajnoczi
2015-06-12 10:09 ` [Qemu-devel] [RFC 7/9] block/backup: support block job transactions Stefan Hajnoczi
2015-06-12 10:09 ` [Qemu-devel] [RFC 8/9] iotests: 124 - transactional failure test Stefan Hajnoczi
2015-06-12 10:09 ` [Qemu-devel] [RFC 9/9] qmp-commands.hx: Update the supported 'transaction' operations Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=558AF8F7.7010803@redhat.com \
--to=mreitz@redhat.com \
--cc=famz@redhat.com \
--cc=jcody@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=vsementsov@parallels.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).