Tarantool development patches archive
 help / color / mirror / Atom feed
From: Alexander Turenko <alexander.turenko@tarantool.org>
To: Timur Safin <tsafin@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org, v.shpilevoy@tarantool.org
Subject: Re: [Tarantool-patches] [PATCH 2.X v3] module api: box_ibuf_* wrappers
Date: Tue, 13 Oct 2020 22:58:29 +0300	[thread overview]
Message-ID: <20201013195829.mrecicqofwk5j36z@tkn_work_nb> (raw)
In-Reply-To: <1ff701d6a193$73c5b6d0$5b512470$@tarantool.org>

> : > +
> : > +#include <trivia/util.h>
> : > +#include <small/ibuf.h>
> : 
> : How about just define an opaque structure?
> 
> Yeah, good point - we are introducing it here just to avoid to have 
> explicit dependency on it in header.

Hm. It is out of /* \cond public */ and /* \endcond public */ markers,
so it's fine from this point of view. But using of `struct ibuf;` in the
header instead of `#include <small/ibuf.h>` should decrease the compile
time a bit. In fact, the time difference is negligible, so the point is
more regarding rules of thumb and feeling about the code as 'clean'.

> 
> : 
> :  | struct ibuf;
> : 
> : But include small/ibuf.h explicitly in the .c file?
> : 

(Cited for convenience.)

> : > +	struct slab_cache *slabc = cord_slab_cache();
> : > +	assert(slabc != NULL);
> : > +	box_ibuf_t ibuf;
> : > +
> : > +	ibuf_create(&ibuf, slabc, 16320);
> : > +	assert(ibuf_used(&ibuf) == 0);
> : > +	box_ibuf_reserve(&ibuf, 65536);
> : > +	char **rpos;
> : > +	char **wpos;
> : > +	box_ibuf_read_range(&ibuf, &rpos, &wpos);
> : > +
> : > +	void *ptr = ibuf_alloc(&ibuf, 10);
> : > +	assert(ptr != NULL);
> : > +
> : > +	assert(ibuf_used(&ibuf) == 10);
> : > +	assert((*wpos - *rpos) == 10);
> : 
> : Now box_ibuf_read_range() should give the updated wpos.
> 
> Here I didn't get your point - wpos and rpos are pointers 
> to fields inside of ibuf structure, they will not change 
> regardless the number of calls to we perform. 

Let's show a sketch:

 | box_ibuf_read_range(&ibuf, &rpos, &wpos);
 | <...do some allocations...>
 | assert((*wpos - *rpos) == 10);

This test case verifies that the positions we obtained before the
allocations are valid after them. I proposed to also verify that
box_ibuf_read_range() will correctly return the positions after the
allocations:

 | box_ibuf_read_range(&ibuf, &rpos, &wpos);
 | <...do some allocations...>
 | assert((*wpos - *rpos) == 10);
 |
 | /* Renew positions and verify them. */
 | box_ibuf_read_range(&ibuf, &rpos, &wpos);
 | assert((*wpos - *rpos) == 10);

> 
> : 
> : > +
> : > +	ptr = ibuf_alloc(&ibuf, 10000);
> : > +	assert(ptr);
> : > +	assert(ibuf_used(&ibuf) == 10010);
> : > +	assert((*wpos - *rpos) == 10010);
> : 
> : Same here.

(Cited for convenience.)

      reply	other threads:[~2020-10-13 19:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-12  0:44 [Tarantool-patches] [PATCH 2.X v3 0/3] module api: extend for external merger Lua module Timur Safin
2020-10-12  0:44 ` [Tarantool-patches] [PATCH 2.X v3 1/3] module api: export box_tuple_validate Timur Safin
2020-10-13  0:14   ` Alexander Turenko
2020-10-13  0:35     ` Timur Safin
2020-10-12  0:44 ` [Tarantool-patches] [PATCH 2.X v3 2/3] module api: export box_key_def_dup Timur Safin
2020-10-13  0:46   ` Alexander Turenko
2020-10-12  0:44 ` [Tarantool-patches] [PATCH 2.X v3 3/3] module api: luaL_checkibuf Timur Safin
2020-10-13 11:47   ` Alexander Turenko
2020-10-13 19:26     ` Igor Munkin
2020-10-13 16:30 ` [Tarantool-patches] [PATCH 2.X v3] module api: box_ibuf_* wrappers Timur Safin
2020-10-13 18:21   ` Alexander Turenko
2020-10-13 19:02     ` Timur Safin
2020-10-13 19:58       ` Alexander Turenko [this message]

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=20201013195829.mrecicqofwk5j36z@tkn_work_nb \
    --to=alexander.turenko@tarantool.org \
    --cc=tarantool-patches@dev.tarantool.org \
    --cc=tsafin@tarantool.org \
    --cc=v.shpilevoy@tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH 2.X v3] module api: box_ibuf_* wrappers' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox