From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <vdavydov.dev@gmail.com>
Date: Thu, 10 Jan 2019 15:29:09 +0300
From: Vladimir Davydov <vdavydov.dev@gmail.com>
Subject: Re: [PATCH v2 2/6] Add functions to ease using Lua iterators from C
Message-ID: <20190110122909.novsa6o6duykot6a@esperanza>
References: <cover.1547064388.git.alexander.turenko@tarantool.org>
 <2c8049118f86934d6088636dba44f92f381ef8ff.1547064388.git.alexander.turenko@tarantool.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2c8049118f86934d6088636dba44f92f381ef8ff.1547064388.git.alexander.turenko@tarantool.org>
To: Alexander Turenko <alexander.turenko@tarantool.org>
Cc: tarantool-patches@freelists.org
List-ID: <tarantool-patches.dev.tarantool.org>

On Wed, Jan 09, 2019 at 11:20:10PM +0300, Alexander Turenko wrote:
> Needed for #3276.

Again, I'm not quite sure that you'll need this patch after you
rework the merger API so I'm not applying it until you send the
new API proposal.

> ---
>  src/lua/utils.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++++
>  src/lua/utils.h | 28 +++++++++++++++++++++

Some tests would be nice to have.

>  2 files changed, 94 insertions(+)
> 
> diff --git a/src/lua/utils.c b/src/lua/utils.c
> index eefb860ee..4d1eee6ab 100644
> --- a/src/lua/utils.c
> +++ b/src/lua/utils.c
> @@ -969,6 +969,72 @@ luaT_state(void)
>  	return tarantool_L;
>  }
>  
> +/* {{{ Helper functions to interact with a Lua iterator from C */
> +
> +struct luaL_iterator {
> +	int gen;
> +	int param;
> +	int state;
> +};
> +
> +struct luaL_iterator *
> +luaL_iterator_new_fromtable(lua_State *L, int idx)
> +{
> +	struct luaL_iterator *it = (struct luaL_iterator *) malloc(

Nit: no need to convert void * to struct luaL_iterator *.

> +		sizeof(struct luaL_iterator));
> +
> +	lua_rawgeti(L, idx, 1); /* Popped by luaL_ref(). */
> +	it->gen = luaL_ref(L, LUA_REGISTRYINDEX);
> +	lua_rawgeti(L, idx, 2); /* Popped by luaL_ref(). */
> +	it->param = luaL_ref(L, LUA_REGISTRYINDEX);
> +	lua_rawgeti(L, idx, 3); /* Popped by luaL_ref(). */
> +	it->state = luaL_ref(L, LUA_REGISTRYINDEX);
> +
> +	return it;
> +}
> +
> +int
> +luaL_iterator_next(lua_State *L, struct luaL_iterator *it)
> +{
> +	int frame_start = lua_gettop(L);
> +
> +	/* Call gen(param, state). */
> +	lua_rawgeti(L, LUA_REGISTRYINDEX, it->gen);
> +	lua_rawgeti(L, LUA_REGISTRYINDEX, it->param);
> +	lua_rawgeti(L, LUA_REGISTRYINDEX, it->state);
> +	lua_call(L, 2, LUA_MULTRET);
> +	int nresults = lua_gettop(L) - frame_start;
> +	if (nresults == 0) {
> +		luaL_error(L, "luaL_iterator_next: gen(param, state) must "
> +			      "return at least one result");
> +		unreachable();
> +		return 0;
> +	}
> +
> +	/* The call above returns nil as the first result. */
> +	if (lua_isnil(L, frame_start + 1)) {
> +		lua_settop(L, frame_start);
> +		return 0;
> +	}
> +
> +	/* Save the first result to it->state. */
> +	luaL_unref(L, LUA_REGISTRYINDEX, it->state);
> +	lua_pushvalue(L, frame_start + 1); /* Popped by luaL_ref(). */
> +	it->state = luaL_ref(L, LUA_REGISTRYINDEX);
> +
> +	return nresults;
> +}
> +
> +void luaL_iterator_free(lua_State *L, struct luaL_iterator *it)
> +{
> +	luaL_unref(L, LUA_REGISTRYINDEX, it->gen);
> +	luaL_unref(L, LUA_REGISTRYINDEX, it->param);
> +	luaL_unref(L, LUA_REGISTRYINDEX, it->state);
> +	free(it);
> +}
> +
> +/* }}} */
> +
>  int
>  tarantool_lua_utils_init(struct lua_State *L)
>  {
> diff --git a/src/lua/utils.h b/src/lua/utils.h
> index bd302d8e9..6ba2e4767 100644
> --- a/src/lua/utils.h
> +++ b/src/lua/utils.h
> @@ -525,6 +525,34 @@ luaL_checkfinite(struct lua_State *L, struct luaL_serializer *cfg,
>  		luaL_error(L, "number must not be NaN or Inf");
>  }
>  
> +/* {{{ Helper functions to interact with a Lua iterator from C */
> +
> +/**
> + * Holds iterator state (references to Lua objects).
> + */
> +struct luaL_iterator;

I'd make luaL_iterator struct transparent so that one could define it
on stack.

> +
> +/**
> + * Create a Lua iterator from {gen, param, state}.

May be, we could pass idx == 0 to create an iterator from
gen, param, state (without a table)? Would it be worthwhile?

> + */
> +struct luaL_iterator *
> +luaL_iterator_new_fromtable(lua_State *L, int idx);

I don't think that _fromtable suffix is really necessary.

> +
> +/**
> + * Move iterator to the next value. Push values returned by
> + * gen(param, state) and return its count. Zero means no more
> + * results available.
> + */
> +int
> +luaL_iterator_next(lua_State *L, struct luaL_iterator *it);
> +
> +/**
> + * Free all resources held by the iterator.
> + */
> +void luaL_iterator_free(lua_State *L, struct luaL_iterator *it);

We usually match _new with _delete.

> +
> +/* }}} */
> +
>  int
>  tarantool_lua_utils_init(struct lua_State *L);