From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp34.i.mail.ru (smtp34.i.mail.ru [94.100.177.94]) (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 8D11C469719 for ; Sat, 10 Oct 2020 00:31:14 +0300 (MSK) References: <20201008213608.1022476-1-gorcunov@gmail.com> <20201008213608.1022476-6-gorcunov@gmail.com> <3cc78ca9-5bf1-0128-1a09-313256be9253@tarantool.org> <20201009065755.GJ2069@grain> From: Vladislav Shpilevoy Message-ID: <8870495c-3e6b-08d1-b4e3-eb2f7fea6c72@tarantool.org> Date: Fri, 9 Oct 2020 23:31:12 +0200 MIME-Version: 1.0 In-Reply-To: <20201009065755.GJ2069@grain> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Tarantool-patches] [PATCH v5 5/6] box/cbox: implement cbox Lua module List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cyrill Gorcunov Cc: tml >>> + >>> + int coro_ref = luaL_ref(tarantool_L, LUA_REGISTRYINDEX); >>> + lua_xmove(L, args_L, lua_gettop(L) - 1); >> >> 2. Why didn't you use lua_remove() to get rid of the unnecessary >> parts of the stack? > > Which one you think is redundant? The object itself? If so then > it sits as a bottom element of the stack and removing it would > simply make code slower. Yes, I see the problem now. First issue is that you can remove the root argument, because it may triggers its GC. Second issue is that you still need luaT_newthread(), because port_lua uses tarantool_L. Both issues can be easily fixed in port_lua. https://github.com/tarantool/tarantool/issues/5406 > Vlad this "prepare environment for calling" part of code is very > sensitive to the arguments, I tried a various combinations in > attempts to get rid of lua thread and none of them work. So I > left it as is and put a FIXME, because it requires more serious > rework. FIXME don't work, they are never fixed after creation unless you have a ticket. Although these times even a ticket tends to be sent to the wishlist for years. >>> + >>> + lua_pushstring(L, "__call"); >>> + lua_pushcfunction(L, lcbox_func_call); >>> + lua_settable(L, -3); >>> + >>> + lua_setmetatable(L, -2); >> >> 3. What happens when the function object is deleted by Lua GC? >> It seems the user can't get the function again without dropping >> it. > > And that is a good question. I must confess I missed Lua GC aspect > here. Thanks a huge! I'll rework! Another thing to look at - on each call you perform a lookup in the function hash. But you don't really need it. You can store the function pointer in a hidden field. For example, in __index metatable of the function object. Or inside the function object with _ prefix, so at least it won't be visible for autocompletion. Or turn the function object into cdata. Anyway you will need it to properly implement a GC handler. And this cdata would be a struct lbox_sym/lbox_func/whatever with the function pointer in it.