tarantool / tarantool / 21990384677

push

github

box: implement Lua call/eval over iproto for application threads

This commit lets a network client specify a thread id to forward
a call/eval request to. To achieve that, we have to initialize
a minimal Lua state in each application threads. We do that by making
the tarantool_L global variable thread-local and factoring out
tarantool_lua_init_minimal() from tarantool_lua_init() for use in
application threads. The minimal initialization includes setting
ctype ids for all our custom Lua types, such as decimal and datetime,
because we need them for MsgPack serialization. These ctype ids are
made thread-local as well. The only exception is tuple because
tuple formats can't be used in any thread except tx. We explicitly
override the tuple decoder to return a plain table instead of a tuple
object if used in a non-tx thread, see luamp_decode_extension_box().

To safely use the box Lua call/eval infrastructure in any thread,
we have to fix a few things:

 1. execute_lua_refs and call_serializer_no_ext have to be made
    thread-local because they depend on the Lua state.
 2. Apart from setting execute_lua_refs and call_serializer_no_ext,
    box_lua_call_init() registers an internal box library and sets
    a trigger on alter of the _func system space. Apparently, we can't
    do that in application threads.
 3. get_call_serializer() uses current_session(), which creates a new
    session object if the current fiber doesn't have a session. Sessions
    aren't thread-safe and we don't set them for fibers running in
    application threads so we switch to fiber_get_session(). We also
    add an explicit check that this is an IPROTO session because for
    other sessions IPROTO feature bits are undefined. The latter is
    merely for code clarity because Lua call/eval are executed only
    from IPROTO.

This commit completes the core part of the application threads
infrastructure.

Closes #12259

NO_DOC=internal
NO_CHANGELOG=internal

70437 of 118503 branches covered (59.44%)

109 of 113 new or added lines in 7 files covered. (96.46%)

105934 of 120883 relevant lines covered (87.63%)

1406548.48 hits per line