From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp51.i.mail.ru (smtp51.i.mail.ru [94.100.177.111]) (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 6422D469719 for ; Thu, 1 Oct 2020 06:35:07 +0300 (MSK) Date: Thu, 1 Oct 2020 06:35:20 +0300 From: Alexander Turenko Message-ID: <20201001033520.w3jebtdr57hfrtcb@tkn_work_nb> References: <6fc62e3a3935978b650fd6d1dcbdef9a5353a1fb.1600955781.git.tsafin@tarantool.org> <40b631b2-c660-32f7-c421-9770d5d06de4@tarantool.org> <20200929051747.caabtjexvamegnno@tkn_work_nb> <0dbdbece-3f14-ba6d-b7ca-50f39f3b46d6@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <0dbdbece-3f14-ba6d-b7ca-50f39f3b46d6@tarantool.org> 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: Vladislav Shpilevoy Cc: tarantool-patches@dev.tarantool.org On Wed, Sep 30, 2020 at 01:21:13AM +0200, Vladislav Shpilevoy wrote: > 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. When we want to call a Lua function (some callback), which can potentially yield (so we can't use luaT_state()), but we have no direct access to some current Lua state. It may be because we're in box C function or because of API design: for merger it is because API of source's virtual functions are Lua agnostic. So... maybe other projects with pure C part and Lua/C part, where C code may call Lua/C code in some way. Say, when there is general pure C code and particular implementation of some API, which works with Lua objects. Something designed as quite extensible thing. Anyway, I already agreed that it is not as simple as cache and we should return back to it later if there will be a need.