From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp47.i.mail.ru (smtp47.i.mail.ru [94.100.177.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id CE679445320 for ; Fri, 17 Jul 2020 06:10:45 +0300 (MSK) Date: Fri, 17 Jul 2020 06:09:59 +0300 From: Alexander Turenko Message-ID: <20200717030959.b4jrn3aq7krpe44h@tkn_work_nb> References: <88f5a7e52eb203bbb959f0f811766887f89371f0.1592416673.git.alexander.turenko@tarantool.org> <20200701203706.GC5559@tarantool.org> <20200716201137.3qvizw3mri64kayv@tkn_work_nb> <20200716223306.GC18920@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200716223306.GC18920@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH v2 3/3] lua: expose temporary Lua state for iproto calls List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Munkin Cc: tarantool-patches@dev.tarantool.org, Vladislav Shpilevoy > > > 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 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 is used). Usage of this function is quite rare, I guess. [1]: https://github.com/tarantool/tarantool/commit/7d0408486571c631e796a90a35adae41cfcd53c9