Re: [Tarantool-patches] [PATCH v2 3/3] lua: expose temporary Lua state for iproto calls

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

> > > Are those conditions below are strictly required by the current
> > > implementation?
> > 
> > When the fiber-local Lua state is present it should not be changed or
> > zapped by the function. I don't know whether it would lead to some
> > negative behaviour changes, but it would be at least counter-intuitive.
> > There is the comment on the topic (I left it cited below).
> 
> My last sentence relates to the check whether fiber-local Lua state is
> present. Long story short, I see no reasons to omit this field
> initialization prior to <box_process_lua> call. Feel free to consider
> this one as a side note with no changes required.

Igor clarified his idea in the offline discussion. Now box_process_lua()
always creates a new Lua thread to serve a call request, but it may
reuse the fiber-local Lua state when it exists. Similarly how
lbox_trigger_run() either use the existing state or create a new one
(see [1]).

The idea looks meaningful. I experimented around and got failed
sql/boolean.test.sql test. It seems I unable to provide a ready patch at
the time: at least I need to debug and polish it, think how to test it,
at max I should look on reusing a Lua state at whole and elaborate
possible approaches.

I think we can proceed with the current 'lua: expose temporary Lua state
for iproto calls' patch, which prevents twice creation of a Lua thread
for background fibers when merger is used or a trigger is run. And then
work on preventing twice creation of a thread for Lua-born fibers (say,
when <box.schema.func.call> is used). Usage of this function is quite
rare, I guess.

[1]: https://github.com/tarantool/tarantool/commit/7d0408486571c631e796a90a35adae41cfcd53c9