Re: [Tarantool-patches] [PATCH 2.X 5/7] module api: luaT_temp_luastate & luaT_release_temp_luastate

[Alexander Turenko <alexander.turenko@tarantool.org>]

>  | diff --git a/src/box/lua/merger.c b/src/box/lua/merger.c
>  | index 583946c4c..a4332e3d6 100644
>  | --- a/src/box/lua/merger.c
>  | +++ b/src/box/lua/merger.c
>  | @@ -530,13 +530,14 @@ luaL_merge_source_buffer_fetch_impl(struct merge_source_buffer *source,
>  |  static int
>  |  luaL_merge_source_buffer_fetch(struct merge_source_buffer *source)
>  |  {
>  | -       int coro_ref = LUA_NOREF;
>  | -       int top = -1;
>  | -       struct lua_State *L = luaT_temp_luastate(&coro_ref, &top);
>  | -       if (L == NULL)
>  | +       int top = lua_gettop(tarantool_L);
>  | +       struct lua_State *L = luaT_newthread(tarantool_L);
>  | +       if (L == NULL) {
>  | +               lua_settop(tarantool_L, top);
>  |                 return -1;
>  | +       }
>  |         int rc = luaL_merge_source_buffer_fetch_impl(source, L);
>  | -       luaT_release_temp_luastate(L, coro_ref, top);
>  | +       lua_settop(tarantool_L, top);
>  |         return rc;
>  |  }
> 
> (The patch is stupid, I know, we should not leave an extra element on
> tarantool_L and yield, but call luaL_ref / luaL_unref with Lua registry
> instead. I forget about this before measurements, but it should not be
> much important here.)

I was bother only about most performant case with the buffer source, but
there are table and tuple sources, which acquires a state per next()
call. Their performance will likely have the same order of degradation,
but per next(), not per chunk fetch. My fault.

OTOH, the merge source API (virtual functions of <struct merge_source>)
now assumes that a merge source may be written in pure C and, what is
more important, may be called from C without any Lua state. We can break
this property of the API in the module and just pass a Lua state to
those functions. It is okay for the Lua/C module: it is always called
from Lua. (The property was nice, though.)

Anyway, it may be resolved within a module either with caching of Lua
states or with contamination of pure C API with <struct lua_State>. And
it may be postponed, because has small effect on the most performant
merge source. So I vote to skip exposing of those APIs from tarantool
for now.