Re: [Tarantool-patches] [PATCH 2.X 3/7] module api: luaT_newthread

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

On Fri, Oct 02, 2020 at 03:26:47PM +0300, Timur Safin wrote:
> : From: Alexander Turenko <alexander.turenko@tarantool.org>
> : Subject: Re: [PATCH 2.X 3/7] module api: luaT_newthread
> : 
> : On Thu, Sep 24, 2020 at 08:00:16PM +0300, Timur Safin wrote:
> : > Exporting `luaT_newthread` as it's necessary for external merger
> : 
> : But you expose accessors for the temporary Lua state in the later patch.
> : Built-in merger only uses luaT_newthread() in luaT_temp_luastate().
> 
> Good point! Indeed - it would be unnecessary iff we keep
> luaT_temp_luastate part of module api...
> 
> But looks like we are not (and would copy corresponding code back to 
> merger' utils code), so we should consider this patch once again as 
> necessary.

It seems, me and Vlad agreed on using lua_newthread() inside the module.
Don't know whether it worth to wrap it with Lua OOM error catching now.
The code at whole should consider possibility of such error, but now it
does not.

Since there is no agreement on this topic, I would say that we should
postpone it until we'll elaborate certain pathway how a module developer
should overcome possible OOM errors. You know, you can get it from any
function that perform allocation of a new Lua object. So protection of
just one allocation function does not change the situation at whole.

Maybe we should elaborate certain recommendations how to determine code
sections that should be protected and how to actually protect them.
Current merger code unlikely handle Lua OOM gracefully.

I would also add here, that a mechanish of Lua OOM error injection is
necessary, because any contract that is not tested is a kind of lie.

WBR, Alexander Turenko.