From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp39.i.mail.ru (smtp39.i.mail.ru [94.100.177.99]) (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 E082E469719 for ; Wed, 30 Sep 2020 02:21:14 +0300 (MSK) References: <6fc62e3a3935978b650fd6d1dcbdef9a5353a1fb.1600955781.git.tsafin@tarantool.org> <40b631b2-c660-32f7-c421-9770d5d06de4@tarantool.org> <20200929051747.caabtjexvamegnno@tkn_work_nb> From: Vladislav Shpilevoy Message-ID: <0dbdbece-3f14-ba6d-b7ca-50f39f3b46d6@tarantool.org> Date: Wed, 30 Sep 2020 01:21:13 +0200 MIME-Version: 1.0 In-Reply-To: <20200929051747.caabtjexvamegnno@tkn_work_nb> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Tarantool-patches] [PATCH 2.X 5/7] module api: luaT_temp_luastate & luaT_release_temp_luastate List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Turenko Cc: tarantool-patches@dev.tarantool.org On 29.09.2020 07:17, Alexander Turenko wrote: > On Tue, Sep 29, 2020 at 12:21:18AM +0200, Vladislav Shpilevoy wrote: >> Thanks for the patch! >> >> I strongly don't like this export. It seems to be too internal. > > I have no point to start discussion. Can you clarify your feeling? I don't like that we give access to fiber's Lua state. If a user will leave anything on it, it can lead to anything as well, UB I guess. But I didn't check. >> But I have no better ideas than propose to implement your own >> lua_State cache in the merger module. It does not seem to be too >> hard, and I don't think it would occupy much memory. >> >> Just a simple list of lua_State objects, created by luaT_newthread >> on demand, and put back into the list when unused. What is wrong >> with that? > > When we able to simplify modules, it worth to do so (when there are no > certain objections). Write once, use many. What are applications for that except the merger? Potentially. >> Adding Igor as Lua master to help with this. >> >> See 2 comments below. >> >>> diff --git a/src/lua/utils.h b/src/lua/utils.h >>> index 9b1fe7e57..da0140076 100644 >>> --- a/src/lua/utils.h >>> +++ b/src/lua/utils.h >>> @@ -554,6 +554,41 @@ luaL_iscallable(lua_State *L, int idx); >>> struct lua_State * >>> luaT_newthread(struct lua_State *L); >>> >>> +/** >>> + * Get a temporary Lua state. >>> + * >>> + * Use case: a function does not accept a Lua state as an argument >>> + * to allow using from C code, but uses a Lua value, which is >>> + * referenced in LUA_REGISTRYINDEX. A temporary Lua stack is needed >>> + * to get and process the value. >>> + * >>> + * The resulting Lua state has a separate Lua stack, but the same >>> + * globals and registry as `tarantool_L` (and all Lua states in >> >> 1. Users don't know what is tarantool_L. > > Note: It is () in the module API. Nice, didn't know that either. But still the comment is invalid.