Re: [Tarantool-patches] [PATCH] lua: refactor port_lua_do_dump and encode_lua_call

[Sergey Kaplun via Tarantool-patches <tarantool-patches@dev.tarantool.org>]

Igor,

On 12.08.21, Igor Munkin wrote:
> Sergey,
> 
> Thanks for the fixes! LGTM, with a several typos in the commit message
> mentioned below. Moreover, please rebase your branch on the current
> master to check nothing is broken.

Branch is rebased, fixes are done, and branch is force-pushed :).

> 
> On 02.08.21, Sergey Kaplun wrote:
> > Hi, Igor!
> > 
> > Thanks for the review!
> > 
> 
> <snipped>
> 
> > 
> > The new commit message is the following:
> > 
> > ===================================================================
> > lua: refactor port_lua_do_dump and encode_lua_call
> > 
> > The old code flow was the following:
> > 
> > 1) `struct port_lua` given to `port_lua_do_dump()` has Lua stack with
> >    arguments to encode to MessagePack.
> > 
> > 2) The main coroutine `tarantool_L` is used to call `encode_lua_call()`
> >    or `encode_lua_call_16`() via `lua_cpcall()`.
> > 
> > 3) Objects on port coroutine are encoded via `luamp_encode()` or
> >    `luamp_encode_call16()`.
> > 
> > 4) This encoding may raise an error on unprotected `port->L` coroutine.
> >    This coroutine has no protected frame on it and this call should fail
> >    in pure Lua.
> > 
> > Calling anything on unprotected coroutine is not allowed in Lua [1]:
> > 
> > | If an error happens outside any protected environment, Lua calls a
> > | panic function
> > 
> > Lua 5.1 sets protection only for specific lua_State [2] and calls a
> > panic function if we raise an error on unprotected lua_State [3].
> > 
> > Nevertheless, no panic occurs now due to two facts:
> > * The first one is LuaJIT's support of C++ exception handling [4] that
> >   allows to raise an error in Lua and catch it in C++ or vice versa. But
> >   documentation still doesn't allow raising errors on unprotected
> >   coroutines (at least we must use try-catch block).
> > * The second one is the patch made in LuaJIT to restore currently
> >   executed coroutine, when C function or fast function raises an
> >   error [5][6] (see the related issue here [7][8]).
> > 
> > For these reasons, when an error occurs, the unwinder searches and finds
> > the C-protected stack frame from the `lua_cpcall()` for `tarantool_L`
> > coroutine and unwinds until that point (without aforementioned patches
> > LuaJIT just calls a panic function and exit).
> 
> Typo: s/exit/exits/.

Fixed.

> 
> > 
> > If an error is raised, and `lua_cpcall()` returns not `LUA_OK`, then the
> > error from `port->L` coroutine is converted into a Tarantool error and a
> > diagnostic is set.
> > 
> > The auxiliary usage of `tarantool_L` coroutine doesn't respect Lua
> > idiomatic of usage. Internal unwinder used on M1 is not such flexible,
> 
> Typo: Too much "usage", so I propose the following wording for the
> previous sentence:
> | Such auxiliary usage of `tarantool_L` is not idiomatic for Lua.

Done.

> 
> > so such misuse leads to panic call. Also the `tarantool_L` usage is
> > redundant. So this patch drops it and uses only minor coroutine instead
> 
> Typo: Again, not minor coroutine, but port coroutine (as we agreed in
> the previous review).

Fixed.

> 
> > with `lua_pcall()`.
> > 
> > Functions to encode are saved as entrance in the `LUA_REGISTRY` table to
> 
> Typo: s/saved as entrance in/saved to/.

Fixed.

> 
> > reduce GC pressure, like it is done for other handlers [9].
> > 
> > [1]: https://www.lua.org/manual/5.2/manual.html#4.6
> > [2]: https://www.lua.org/source/5.1/lstate.h.html#lua_State
> > [3]: https://www.lua.org/source/5.1/ldo.c.html#luaD_throw
> > [4]: https://luajit.org/extensions.html#exceptions
> > [5]: https://github.com/tarantool/luajit/commit/ed412cd9f55fe87fd32a69c86e1732690fc5c1b0
> > [6]: https://github.com/tarantool/luajit/commit/97699d9ee2467389b6aea21a098e38aff3469b5f
> > [7]: https://github.com/tarantool/tarantool/issues/1516
> > [8]: https://www.freelists.org/post/luajit/Issue-with-PCALL-in-21
> > [9]: https://github.com/tarantool/tarantool/commit/e88c0d21ab765d4c53bed2437c49d77b3ffe4216
> > 
> > Closes #6248
> > Closes #4617
> > ===================================================================
> > 
> > > > ---
> > > > 
> > > > Branch: https://github.com/tarantool/tarantool/tree/skaplun/gh-noticket-refactor-lua-call

<snipped>


-- 
Best regards,
Sergey Kaplun