From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp5.mail.ru (smtp5.mail.ru [94.100.179.24]) (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 F0F9E469719 for ; Sat, 3 Oct 2020 05:15:52 +0300 (MSK) Date: Sat, 3 Oct 2020 05:16:05 +0300 From: Alexander Turenko Message-ID: <20201003021605.mrapm66vdkktbu7j@tkn_work_nb> References: <6fc62e3a3935978b650fd6d1dcbdef9a5353a1fb.1600955781.git.tsafin@tarantool.org> <40b631b2-c660-32f7-c421-9770d5d06de4@tarantool.org> <20200929151002.GY18920@tarantool.org> <20200929210345.jseljymlmkgdrp3c@tkn_work_nb> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200929210345.jseljymlmkgdrp3c@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: Igor Munkin Cc: tarantool-patches@dev.tarantool.org, Vladislav Shpilevoy > | diff --git a/src/box/lua/merger.c b/src/box/lua/merger.c > | index 583946c4c..a4332e3d6 100644 > | --- a/src/box/lua/merger.c > | +++ b/src/box/lua/merger.c > | @@ -530,13 +530,14 @@ luaL_merge_source_buffer_fetch_impl(struct merge_source_buffer *source, > | static int > | luaL_merge_source_buffer_fetch(struct merge_source_buffer *source) > | { > | - int coro_ref = LUA_NOREF; > | - int top = -1; > | - struct lua_State *L = luaT_temp_luastate(&coro_ref, &top); > | - if (L == NULL) > | + int top = lua_gettop(tarantool_L); > | + struct lua_State *L = luaT_newthread(tarantool_L); > | + if (L == NULL) { > | + lua_settop(tarantool_L, top); > | return -1; > | + } > | int rc = luaL_merge_source_buffer_fetch_impl(source, L); > | - luaT_release_temp_luastate(L, coro_ref, top); > | + lua_settop(tarantool_L, top); > | return rc; > | } > > (The patch is stupid, I know, we should not leave an extra element on > tarantool_L and yield, but call luaL_ref / luaL_unref with Lua registry > instead. I forget about this before measurements, but it should not be > much important here.) I was bother only about most performant case with the buffer source, but there are table and tuple sources, which acquires a state per next() call. Their performance will likely have the same order of degradation, but per next(), not per chunk fetch. My fault. OTOH, the merge source API (virtual functions of ) now assumes that a merge source may be written in pure C and, what is more important, may be called from C without any Lua state. We can break this property of the API in the module and just pass a Lua state to those functions. It is okay for the Lua/C module: it is always called from Lua. (The property was nice, though.) Anyway, it may be resolved within a module either with caching of Lua states or with contamination of pure C API with . And it may be postponed, because has small effect on the most performant merge source. So I vote to skip exposing of those APIs from tarantool for now.