Tarantool development patches archive
 help / color / mirror / Atom feed
From: Vitaliia Ioffe via Tarantool-patches <tarantool-patches@dev.tarantool.org>
To: "Sergey Kaplun" <skaplun@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org,
	"Vladislav Shpilevoy" <v.shpilevoy@tarantool.org>
Subject: Re: [Tarantool-patches]  [PATCH] lua: refactor port_lua_do_dump and encode_lua_call
Date: Fri, 13 Aug 2021 10:41:18 +0300
Message-ID: <1628840478.327731576@f491.i.mail.ru> (raw)
In-Reply-To: <YRYfoNfM57HrSn+8@root>

[-- Attachment #1: Type: text/plain, Size: 4552 bytes --]


Hi team, 
 
QA LGTM!
 
 
--
Vitaliia Ioffe
 
  
>Пятница, 13 августа 2021, 10:32 +03:00 от 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
 

[-- Attachment #2: Type: text/html, Size: 6778 bytes --]

  reply	other threads:[~2021-08-13  7:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-18 18:14 Sergey Kaplun via Tarantool-patches
2021-06-21 20:36 ` Vladislav Shpilevoy via Tarantool-patches
2021-06-22 13:38   ` Sergey Kaplun via Tarantool-patches
2021-06-24 20:00     ` Vladislav Shpilevoy via Tarantool-patches
2021-06-29  7:07       ` Sergey Kaplun via Tarantool-patches
2021-08-01 12:34 ` Igor Munkin via Tarantool-patches
2021-08-02 14:25   ` Sergey Kaplun via Tarantool-patches
2021-08-12 17:35     ` Igor Munkin via Tarantool-patches
2021-08-13  7:30       ` Sergey Kaplun via Tarantool-patches
2021-08-13  7:41         ` Vitaliia Ioffe via Tarantool-patches [this message]
2021-08-13  9:27         ` Sergey Kaplun via Tarantool-patches
2021-08-04 22:29 ` Vladislav Shpilevoy via Tarantool-patches
2021-08-14 10:16 ` Igor Munkin via Tarantool-patches

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1628840478.327731576@f491.i.mail.ru \
    --to=tarantool-patches@dev.tarantool.org \
    --cc=skaplun@tarantool.org \
    --cc=v.ioffe@tarantool.org \
    --cc=v.shpilevoy@tarantool.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Tarantool development patches archive

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://lists.tarantool.org/tarantool-patches/0 tarantool-patches/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 tarantool-patches tarantool-patches/ https://lists.tarantool.org/tarantool-patches \
		tarantool-patches@dev.tarantool.org.
	public-inbox-index tarantool-patches

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git