All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tommi Virtanen <tommi.virtanen@dreamhost.com>
To: Sage Weil <sage@newdream.net>
Cc: ceph-devel@vger.kernel.org
Subject: Re: librados compound operations
Date: Mon, 28 Mar 2011 16:41:05 -0700	[thread overview]
Message-ID: <20110328234104.GD10768@dreamer> (raw)
In-Reply-To: <Pine.LNX.4.64.1103281539580.17288@cobra.newdream.net>

On Mon, Mar 28, 2011 at 03:46:21PM -0700, Sage Weil wrote:
> One weird thing I noticed is with the constructor.  In Rados:: did
> 
> +    static ObjectOperation *operation_create();
> 
> and the user then deletes it when they're done (after using it for one or 
> more calls to operate() or aio_operate()).  Is that the the approach we 
> want?  Because right above that in the header is
> 
>      int ioctx_create(const char *name, IoCtx &pioctx);
> 
> which is a totally different convention.  It does match

The usual argument about that is that returning a pointer is only good
when the only possible failure, now and forever, is running out of
memory. The int can communicate more reasons for failure.

So the real question to ask is, how guaranteed is that to work? For
example, in the case of ioctx, the extra name argument might need to
be unique among concurrent operations, etc.

> +void librados::ObjectOperation::write(uint64_t off, const bufferlist& bl)
> +{
> +  ::ObjectOperation *o = (::ObjectOperation *)impl;
> +  bufferlist c = bl;
> +  o->write(off, c);
> +}

Losing constness always makes me a bit sad.

-- 
:(){ :|:&};:

  reply	other threads:[~2011-03-28 23:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-28 22:46 librados compound operations Sage Weil
2011-03-28 23:41 ` Tommi Virtanen [this message]
2011-03-28 23:53   ` Sage Weil
2011-03-29  1:29 ` Colin McCabe
2011-03-29 16:27   ` Sage Weil

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=20110328234104.GD10768@dreamer \
    --to=tommi.virtanen@dreamhost.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=sage@newdream.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.