Tarantool development patches archive
 help / color / mirror / Atom feed
From: Alexander Turenko <alexander.turenko@tarantool.org>
To: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: tarantool-patches@freelists.org
Subject: Re: [PATCH v3 7/7] Add merger for tuple streams (Lua part)
Date: Wed, 8 May 2019 01:14:43 +0300	[thread overview]
Message-ID: <20190507221442.gocz6rpnctp245pj@tkn_work_nb> (raw)
In-Reply-To: <20190430173724.fgvtexkhbdutrt5x@esperanza>

Thanks!

I'll send 4th version of the patchset.

WBR, Alexander Turenko.

On Tue, Apr 30, 2019 at 08:37:24PM +0300, Vladimir Davydov wrote:
> On Wed, Apr 10, 2019 at 06:21:25PM +0300, Alexander Turenko wrote:
> > A merger is a special kind of a source, which is created from a key_def
> > object and a set of sources. It performs a kind of the merge sort:
> > chooses a source with a minimal / maximal tuple on each step, consumes
> > a tuple from this source and repeats. The API to create a merger is the
> > following:
> > 
> > ```lua
> > local ctx = merger.context.new(key_def.new(<...>))
> 
> Discussed verbally, agreed that a performance gain from using
> merger.context is somewhat dubious. It's compelling to drop it
> altogether and pass key_def to merger.new directly, creating
> a format every time (we can reuse formats if necessary in future).
> Alexander will think about it.

Okay. Removed.

I'll suggest to cache a key_def instead of a merge context in
tarantool-merger-examples.

> 
> Other than that the API and the patch looks good to me.
> 
> See a few minor comments below.
> 
> > local sources = {<...>}
> > local merger_inst = merger.new(ctx, sources, {
> >     -- Ascending (false) or descending (true) order.
> >     -- Default is ascending.
> >     reverse = <boolean> or <nil>,
> > })
> > ```
> 
> > diff --git a/src/box/lua/merger.c b/src/box/lua/merger.c
> > new file mode 100644
> > index 000000000..ebe60bc8d
> > --- /dev/null
> > +++ b/src/box/lua/merger.c
> > @@ -0,0 +1,1184 @@
> 
> > +static uint32_t merger_source_type_id = 0;
> > +static uint32_t merger_context_type_id = 0;
> > +static uint32_t ibuf_type_id = 0;
> 
> We typically use upper case for naming variables storing Lua type ids,
> e.g. CTID_STRUCT_TUPLE_REF.

Changed to CTID_STRUCT_IBUF and CTID_STRUCT_MERGE_SOURCE_REF.

> 
> > +static int
> > +lbox_merger_source_gc(struct lua_State *L)
> > +{
> > +	struct merger_source *source;
> > +	if ((source = luaT_check_merger_source(L, 1)) == NULL)
> > +		return 0;
> 
> Is it actually possible?

No. It was carried from the original shard/driver.c, but tarantool's
code don't perform such checks. Replaced with assert.

> 
> > +	merger_source_unref(source);
> > +	return 0;
> > +}
> 
> > +static struct merger_source **
> > +luaT_merger_new_parse_sources(struct lua_State *L, int idx,
> > +			      uint32_t *sources_count_ptr)
> > +{
> > +	/* Allocate sources array. */
> > +	uint32_t sources_count = lua_objlen(L, idx);
> > +	const ssize_t sources_size =
> > +		sources_count * sizeof(struct merger_source *);
> > +	struct merger_source **sources =
> > +		(struct merger_source **) malloc(sources_size);
> 
> Pointless type conversion.

Removed. Also changed the order from `count * sizeof(...)` to
`sizeof(...) * count` where we allocate arrays to do the arithmetic in
size_t. There is no real reason, just to do things in the right way.

Also fixed the place (it is this function) where I mistakely save an
array size into a ssize_t (signed) variable.

> 
> > +	if (sources == NULL) {
> > +		diag_set(OutOfMemory, sources_size, "malloc", "sources");
> > +		return NULL;
> > +	}
> > +
> > +	/* Save all sources. */
> > +	for (uint32_t i = 0; i < sources_count; ++i) {
> > +		lua_pushinteger(L, i + 1);
> > +		lua_gettable(L, idx);
> > +
> > +		/* Extract a source from a Lua stack. */
> > +		struct merger_source *source = luaT_check_merger_source(L, -1);
> > +		if (source == NULL) {
> > +			free(sources);
> > +			diag_set(IllegalParams,
> > +				 "Unknown source type at index %d", i + 1);
> > +			return NULL;
> > +		}
> > +		sources[i] = source;
> > +	}
> > +	lua_pop(L, sources_count);
> > +
> > +	*sources_count_ptr = sources_count;
> 
> source_count

Changed all *_count names in that way and also changed all *_cnt to
*_count.

> 
> > +struct merger_source_buffer {
> > +	struct merger_source base;
> > +	/*
> > +	 * A reference to a Lua iterator to fetch a next chunk of
> > +	 * tuples.
> > +	 */
> > +	struct luaL_iterator *fetch_it;
> > +	/*
> > +	 * A reference a buffer with a current chunk of tuples.
> 
> A reference to a buffer storing the current chunk of tuples.

I don't get why 'THE current chunk', but changed as you suggested
anyway.

> 
> > +	 * It is needed to prevent LuaJIT from collecting the
> > +	 * buffer while the source consider it as the current
> > +	 * one.
> > +	 */
> > +	int ref;
> > +	/*
> > +	 * A buffer with a current chunk of tuples.
> > +	 */
> > +	struct ibuf *buf;
> > +	/*
> > +	 * A merger stops before end of a buffer when it is not
> > +	 * the last merger in the chain.
> > +	 */
> > +	size_t remaining_tuples_cnt;
> 
> Please rename to remaining_tuple_count.

Done.

> 
> > +static int
> > +luaL_merger_source_buffer_fetch(struct merger_source_buffer *source)
> > +{
> > +	struct lua_State *L = fiber()->storage.lua.stack;
> > +	int nresult = luaL_iterator_next(L, source->fetch_it);
> > +
> > +	/* Handle a Lua error in a gen function. */
> > +	if (nresult == -1)
> > +		return -1;
> > +
> > +	/* No more data: do nothing. */
> > +	if (nresult == 0)
> > +		return 0;
> > +
> > +	/* Handle incorrect results count. */
> > +	if (nresult != 2) {
> > +		diag_set(IllegalParams, "Expected <state>, <buffer>, got %d "
> > +			 "return values", nresult);
> > +		return -1;
> > +	}
> > +
> > +	/* Set a new buffer as the current chunk. */
> > +	if (source->ref > 0)
> > +		luaL_unref(L, LUA_REGISTRYINDEX, source->ref);
> > +	lua_pushvalue(L, -nresult + 1); /* Popped by luaL_ref(). */
> > +	source->ref = luaL_ref(L, LUA_REGISTRYINDEX);
> > +	source->buf = luaT_check_ibuf(L, -1);
> > +	assert(source->buf != NULL);
> 
>  | tarantool> m = merger.new(c, {merger.new_buffer_source(box.space._space:pairs())})
>  | ---
>  | ...
>  | 
>  | tarantool> m:select()
>  | luaL_merger_source_buffer_fetch: Assertion `source->buf != NULL' failed.
> 
> Please fail gracefully in this case.

Nice catch. Fixed. Added 'bad_chunks' test cases.

> 
> > +	lua_pop(L, nresult);
> > +
> > +	/* Update remaining_tuples_cnt and skip the header. */
> > +	if (decode_header(source->buf, &source->remaining_tuples_cnt) != 0) {
> > +		diag_set(IllegalParams, "Invalid merger source %p",
> > +			 &source->base);
> > +		return -1;
> > +	}
> > +	return 1;
> > +}
> > +
> > +/* Virtual methods */
> > +
> > +static void
> > +luaL_merger_source_buffer_delete(struct merger_source *base)
> > +{
> > +	struct merger_source_buffer *source = container_of(base,
> > +		struct merger_source_buffer, base);
> > +
> > +	assert(source->fetch_it != NULL);
> > +	luaL_iterator_delete(source->fetch_it);
> > +	if (source->ref > 0)
> > +		luaL_unref(tarantool_L, LUA_REGISTRYINDEX, source->ref);
> > +
> > +	free(source);
> > +}
> > +
> > +static int
> > +luaL_merger_source_buffer_next(struct merger_source *base,
> > +			       box_tuple_format_t *format,
> > +			       struct tuple **out)
> > +{
> > +	struct merger_source_buffer *source = container_of(base,
> > +		struct merger_source_buffer, base);
> > +
> > +	/*
> > +	 * Handle the case when all data were processed: ask a
> > +	 * next chunk until a non-empty chunk is received or a
> > +	 * chunks iterator ends.
> > +	 */
> > +	while (source->remaining_tuples_cnt == 0) {
> > +		int rc = luaL_merger_source_buffer_fetch(source);
> > +		if (rc < 0)
> > +			return -1;
> > +		if (rc == 0) {
> > +			*out = NULL;
> > +			return 0;
> > +		}
> > +	}
> > +	if (ibuf_used(source->buf) == 0) {
> > +		diag_set(IllegalParams, "Unexpected msgpack buffer end");
> > +		return -1;
> > +	}
> > +	const char *tuple_beg = source->buf->rpos;
> > +	const char *tuple_end = tuple_beg;
> > +	/*
> > +	 * mp_next() is faster then mp_check(), but can	read bytes
> > +	 * outside of the buffer and so can cause segmentation
> > +	 * faults or an incorrect result.
> > +	 *
> > +	 * We check buffer boundaries after the mp_next() call and
> > +	 * throw an error when the boundaries are violated, but it
> > +	 * does not save us from possible segmentation faults.
> > +	 *
> > +	 * It is in a user responsibility to provide valid
> > +	 * msgpack.
> 
> Ugh, I'd check the buffer with mp_check anyway. Would probably provide
> an option to skip the check if required ('unchecked'). Not sure if it's
> really necessary though.

Okay.

> 
> > +	 */
> > +	mp_next(&tuple_end);
> > +	--source->remaining_tuples_cnt;
> > +	if (tuple_end > source->buf->wpos) {
> > +		diag_set(IllegalParams, "Unexpected msgpack buffer end");
> > +		return -1;
> > +	}
> > +	source->buf->rpos = (char *) tuple_end;
> > +	if (format == NULL)
> > +		format = box_tuple_format_default();
> 
> I'd pass tuple_format_runtime explicitly to the ->next callback.
> Special-casing NULL is kinda ugly.

NULL value for a format has the special meaning for source->next(): it
does not matter for a caller in which format a resulting tuple will be
(see the comment for next() in struct merge_source_vtab). It is not
always means that a tuple will be in the runtime format: say, for a
tuple source it means that it will return tuples in its original format.
The same is applicable for a table source when a chunk contains tuples
(not Lua tables).

This does not matter much for a buffer source, but it is the part of a
source contract in general. I'll leave it as is if you don't mind.

> 
> > +	struct tuple *tuple = box_tuple_new(format, tuple_beg, tuple_end);
> > +	if (tuple == NULL)
> > +		return -1;
> > +
> > +	box_tuple_ref(tuple);
> > +	*out = tuple;
> > +	return 0;
> > +}
> 
> > +static int
> > +encode_result_buffer(struct lua_State *L, struct merger_source *source,
> > +		     struct ibuf *obuf, uint32_t limit)
> 
> Better rename 'obuf' to 'out' or 'buf' or something - we have struct
> obuf so 'struct ibuf *obuf' looks misleading.

We use 'buf' where reading from it, so I would use some another name
when writing. 'out' looks more appropriate for a scalar / pointer value
we'll replace in a function. I'll use 'output_buffer' here and in other
such places in C and Lua if you don't mind.

> 
> > +{
> > +	uint32_t result_len = 0;
> > +	uint32_t result_len_offset = 4;
> > +
> > +	/*
> > +	 * Reserve maximum size for the array around resulting
> > +	 * tuples to set it later.
> > +	 */
> > +	encode_header(obuf, UINT32_MAX);
> > +
> > +	/* Fetch, merge and copy tuples to the buffer. */
> > +	struct tuple *tuple;
> > +	int rc = 0;
> > +	while (result_len < limit && (rc =
> > +	       source->vtab->next(source, NULL, &tuple)) == 0 &&
> > +	       tuple != NULL) {
> > +		uint32_t bsize = tuple->bsize;
> > +		ibuf_reserve(obuf, bsize);
> > +		memcpy(obuf->wpos, tuple_data(tuple), bsize);
> > +		obuf->wpos += bsize;
> > +		result_len_offset += bsize;
> > +		++result_len;
> > +
> > +		/* The received tuple is not more needed. */
> > +		box_tuple_unref(tuple);
> > +	}
> > +
> > +	if (rc != 0)
> > +		return luaT_error(L);
> > +
> > +	/* Write the real array size. */
> > +	mp_store_u32(obuf->wpos - result_len_offset, result_len);
> > +
> > +	return 0;
> > +}
> 
> > +static int
> > +lbox_merger_source_select(struct lua_State *L)
> > +{
> > +	struct merger_source *source;
> > +	int top = lua_gettop(L);
> > +	bool ok = (top == 1 || top == 2) &&
> > +		/* Merger source. */
> > +		(source = luaT_check_merger_source(L, 1)) != NULL &&
> > +		/* Opts. */
> > +		(lua_isnoneornil(L, 2) == 1 || lua_istable(L, 2) == 1);
> > +	if (!ok)
> > +		return lbox_merger_source_select_usage(L, NULL);
> > +
> > +	uint32_t limit = 0xFFFFFFFF;
> 
> Hmm, UINT32_MAX?

Okay, changed.

      parent reply	other threads:[~2019-05-07 22:14 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-10 15:21 [PATCH v3 0/7] Merger Alexander Turenko
2019-04-10 15:21 ` [PATCH v3 1/7] Add luaL_iscallable with support of cdata metatype Alexander Turenko
2019-04-18 17:30   ` [tarantool-patches] " Konstantin Osipov
2019-04-30 12:45   ` Vladimir Davydov
2019-04-10 15:21 ` [PATCH v3 2/7] Add functions to ease using Lua iterators from C Alexander Turenko
2019-04-18 17:31   ` [tarantool-patches] " Konstantin Osipov
2019-04-30 12:46   ` Vladimir Davydov
2019-04-10 15:21 ` [PATCH v3 3/7] lua: optimize creation of a tuple from a tuple Alexander Turenko
2019-04-18 17:32   ` [tarantool-patches] " Konstantin Osipov
2019-04-30 12:50   ` Vladimir Davydov
2019-04-30 15:07     ` Alexander Turenko
2019-04-10 15:21 ` [PATCH v3 4/7] lua: add non-recursive msgpack decoding functions Alexander Turenko
2019-04-18 17:35   ` [tarantool-patches] " Konstantin Osipov
2019-04-18 18:30     ` Alexander Turenko
2019-04-18 18:33       ` Konstantin Osipov
2019-04-18 18:44         ` Alexander Turenko
2019-04-30 13:03   ` Vladimir Davydov
2019-04-30 18:38     ` Alexander Turenko
2019-04-10 15:21 ` [PATCH v3 5/7] net.box: add skip_header option to use with buffer Alexander Turenko
2019-04-18 17:37   ` [tarantool-patches] " Konstantin Osipov
2019-04-18 18:39     ` Alexander Turenko
2019-04-30 13:16   ` Vladimir Davydov
2019-04-30 18:39     ` Alexander Turenko
2019-04-10 15:21 ` [PATCH v3 6/7] Add merger for tuples streams (C part) Alexander Turenko
2019-04-25 11:43   ` [tarantool-patches] " Konstantin Osipov
2019-04-25 13:32     ` Alexander Turenko
2019-04-25 13:45       ` Konstantin Osipov
2019-04-25 15:32         ` [tarantool-patches] " Alexander Turenko
2019-04-25 16:42           ` Konstantin Osipov
2019-04-30 15:34   ` Vladimir Davydov
2019-05-07 22:14     ` Alexander Turenko
2019-04-10 15:21 ` [PATCH v3 7/7] Add merger for tuple streams (Lua part) Alexander Turenko
2019-04-25 11:46   ` [tarantool-patches] " Konstantin Osipov
2019-04-25 12:53     ` Alexander Turenko
2019-04-25 13:30       ` Konstantin Osipov
2019-04-30 17:37   ` Vladimir Davydov
2019-04-30 21:09     ` [tarantool-patches] " Konstantin Osipov
2019-05-02  9:48       ` Vladimir Davydov
2019-05-07 22:14     ` 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=20190507221442.gocz6rpnctp245pj@tkn_work_nb \
    --to=alexander.turenko@tarantool.org \
    --cc=tarantool-patches@freelists.org \
    --cc=vdavydov.dev@gmail.com \
    --subject='Re: [PATCH v3 7/7] Add merger for tuple streams (Lua part)' \
    /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