From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149]) (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 8400E44643B for ; Thu, 15 Oct 2020 02:41:46 +0300 (MSK) References: <33039bab-b31e-0da7-359d-dbbc8464aa55@tarantool.org> <20201012103707.kzx54ljqq67eazrc@tkn_work_nb> From: Vladislav Shpilevoy Message-ID: <965ed904-a5d5-f0b6-a779-d120ec9761f0@tarantool.org> Date: Thu, 15 Oct 2020 01:41:45 +0200 MIME-Version: 1.0 In-Reply-To: <20201012103707.kzx54ljqq67eazrc@tkn_work_nb> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Tarantool-patches] [PATCH v2 05/15] lua: don't raise a Lua error from luaT_tuple_new() List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Turenko Cc: tarantool-patches@dev.tarantool.org On 12.10.2020 12:37, Alexander Turenko wrote: >>> Disallow creating a tuple from objects on the Lua stack (idx == 0) in >>> luaT_tuple_new() for simplicity. There are no such usages in tarantool. >>> The function is not exposed yet to the module API. This is only >>> necessary in box.tuple.new(), which anyway raises Lua errors by its >>> contract. >> >> 1. But why? The case of creating a tuple from values may be much faster, >> when there is a lot of values not wrapped into a table. Table wrap is >> costly. >> >> Could you just merge luaT_tuple_encode_values and luaT_tuple_encode_table >> into one function, withuout splitting them? > > I started with this variant, but then found that it'll require copying > of all arguments before pcall() (at least if we must leave them on the > stack after exiting from the function). Even if we'll decide to include > a remark like 'the function pops all values in case of idx == 0', we'll > need to put a function before the arguments and so we'll move all stack > values. Anyway it looks lopsided: in one case arguments are popped, but > in another they are kept on the stack. > > I guess it would have a chance to be useful if it would allow to pass a > range of lua stack indices. But not sure. I created an issue for that: https://github.com/tarantool/tarantool/issues/5406 (At least it is related, and this place is not the only problematic one.)