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

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

On Tue, Sep 29, 2020 at 12:21:18AM +0200, Vladislav Shpilevoy wrote:
> Thanks for the patch!
> 
> I strongly don't like this export. It seems to be too internal.

I have no point to start discussion. Can you clarify your feeling?

> 
> But I have no better ideas than propose to implement your own
> lua_State cache in the merger module. It does not seem to be too
> hard, and I don't think it would occupy much memory.
> 
> Just a simple list of lua_State objects, created by luaT_newthread
> on demand, and put back into the list when unused. What is wrong
> with that?

When we able to simplify modules, it worth to do so (when there are no
certain objections). Write once, use many.

> 
> Adding Igor as Lua master to help with this.
> 
> See 2 comments below.
> 
> > diff --git a/src/lua/utils.h b/src/lua/utils.h
> > index 9b1fe7e57..da0140076 100644
> > --- a/src/lua/utils.h
> > +++ b/src/lua/utils.h
> > @@ -554,6 +554,41 @@ luaL_iscallable(lua_State *L, int idx);
> >  struct lua_State *
> >  luaT_newthread(struct lua_State *L);
> >  
> > +/**
> > + * Get a temporary Lua state.
> > + *
> > + * Use case: a function does not accept a Lua state as an argument
> > + * to allow using from C code, but uses a Lua value, which is
> > + * referenced in LUA_REGISTRYINDEX. A temporary Lua stack is needed
> > + * to get and process the value.
> > + *
> > + * The resulting Lua state has a separate Lua stack, but the same
> > + * globals and registry as `tarantool_L` (and all Lua states in
> 
> 1. Users don't know what is tarantool_L.

Note: It is <luaT_state>() in the module API.