From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp16.mail.ru (smtp16.mail.ru [94.100.176.153]) (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 3BC7B469719 for ; Fri, 2 Oct 2020 15:53:39 +0300 (MSK) Date: Fri, 2 Oct 2020 15:53:52 +0300 From: Alexander Turenko Message-ID: <20201002125352.qktch5vzkxiidk3p@tkn_work_nb> References: <20200929062543.rfjus76ii2lxqodu@tkn_work_nb> <09e801d698b7$4c3c36a0$e4b4a3e0$@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <09e801d698b7$4c3c36a0$e4b4a3e0$@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH 2.X 3/7] module api: luaT_newthread List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Timur Safin Cc: tarantool-patches@dev.tarantool.org, v.shpilevoy@tarantool.org On Fri, Oct 02, 2020 at 03:26:47PM +0300, Timur Safin wrote: > : From: Alexander Turenko > : Subject: Re: [PATCH 2.X 3/7] module api: luaT_newthread > : > : On Thu, Sep 24, 2020 at 08:00:16PM +0300, Timur Safin wrote: > : > Exporting `luaT_newthread` as it's necessary for external merger > : > : But you expose accessors for the temporary Lua state in the later patch. > : Built-in merger only uses luaT_newthread() in luaT_temp_luastate(). > > Good point! Indeed - it would be unnecessary iff we keep > luaT_temp_luastate part of module api... > > But looks like we are not (and would copy corresponding code back to > merger' utils code), so we should consider this patch once again as > necessary. It seems, me and Vlad agreed on using lua_newthread() inside the module. Don't know whether it worth to wrap it with Lua OOM error catching now. The code at whole should consider possibility of such error, but now it does not. Since there is no agreement on this topic, I would say that we should postpone it until we'll elaborate certain pathway how a module developer should overcome possible OOM errors. You know, you can get it from any function that perform allocation of a new Lua object. So protection of just one allocation function does not change the situation at whole. Maybe we should elaborate certain recommendations how to determine code sections that should be protected and how to actually protect them. Current merger code unlikely handle Lua OOM gracefully. I would also add here, that a mechanish of Lua OOM error injection is necessary, because any contract that is not tested is a kind of lie. WBR, Alexander Turenko.