qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

  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).