From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpng2.m.smailru.net (smtpng2.m.smailru.net [94.100.179.3]) (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 AB4BF469719 for ; Thu, 1 Oct 2020 18:17:00 +0300 (MSK) Date: Thu, 1 Oct 2020 18:06:25 +0300 From: Igor Munkin Message-ID: <20201001150625.GE18920@tarantool.org> References: <6fc62e3a3935978b650fd6d1dcbdef9a5353a1fb.1600955781.git.tsafin@tarantool.org> <40b631b2-c660-32f7-c421-9770d5d06de4@tarantool.org> <20200929151002.GY18920@tarantool.org> <20200929210345.jseljymlmkgdrp3c@tkn_work_nb> <20200930100928.ybprk7zniggipe45@tkn_work_nb> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200930100928.ybprk7zniggipe45@tkn_work_nb> 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 , s@tarantool.org Cc: tarantool-patches@dev.tarantool.org, Vladislav Shpilevoy Sasha, Thanks a lot for the benchmarks and clarifications! On 30.09.20, Alexander Turenko wrote: > On Wed, Sep 30, 2020 at 01:23:17AM +0200, Vladislav Shpilevoy wrote: > > The performance difference also looks small (I shared benchmarking results > in this mailing thread). Since there are questions about design of those > functions, I would use lua_newthread() (or wrapper around it to handle > OOM -- written in the module). We can return back to this API later. > Perfect! I would gladly join the discussion and design for the vital public API interfaces. > > > > It is not that simple. Whatever you export now, we will need to support > > potentially forever. So exporting not vital things increases support costs > > for us for a very long time by saving a few time to you and Timur so you > > don't need to change merger code and can move it as is. I would better > > one time made merger less depending on Tarantool internals, then do long > > support of the new pile of internal methods exposed in a hurry. > > I agree, but also I consider this activity as good opportunity to > improve the module API. Of course, when we have good design. I agree with Vlad here. I totally understand your motivation but I strongly doubt we should mix these issues (i.e. exporting the methods necessary for merger and public API enhancements). -- Best regards, IM