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

[Alexander Turenko]

On Wed, Sep 30, 2020 at 01:21:13AM +0200, Vladislav Shpilevoy wrote:
> On 29.09.2020 07:17, Alexander Turenko wrote:
> > 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?
> 
> I don't like that we give access to fiber's Lua state. If a user will
> leave anything on it, it can lead to anything as well, UB I guess. But
> I didn't check.
> 
> >> 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.
> 
> What are applications for that except the merger? Potentially.

When we want to call a Lua function (some callback), which can
potentially yield (so we can't use luaT_state()), but we have no direct
access to some current Lua state. It may be because we're in box C
function or because of API design: for merger it is because API of
source's virtual functions are Lua agnostic.

So... maybe other projects with pure C part and Lua/C part, where C code
may call Lua/C code in some way. Say, when there is general pure C code and
particular implementation of some API, which works with Lua objects.
Something designed as quite extensible thing.

Anyway, I already agreed that it is not as simple as cache and we should
return back to it later if there will be a need.