From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp59.i.mail.ru (smtp59.i.mail.ru [217.69.128.39]) (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 B385B469719 for ; Mon, 12 Oct 2020 13:36:48 +0300 (MSK) Date: Mon, 12 Oct 2020 13:37:07 +0300 From: Alexander Turenko Message-ID: <20201012103707.kzx54ljqq67eazrc@tkn_work_nb> References: <33039bab-b31e-0da7-359d-dbbc8464aa55@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <33039bab-b31e-0da7-359d-dbbc8464aa55@tarantool.org> 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: Vladislav Shpilevoy Cc: tarantool-patches@dev.tarantool.org > > 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. If we'll find it actually useful, nothing prevent us from exposing luaT_tuple_field_encode() (to control what to encode from a Lua stack in a user side code). Or consider some other way (even support idx == 0 in luaT_tuple_encode()): a real use case will help us with designing good API. > > diff --git a/src/box/lua/tuple.c b/src/box/lua/tuple.c > > index ed97c85e4..18cfef979 100644 > > --- a/src/box/lua/tuple.c > > +++ b/src/box/lua/tuple.c > > @@ -69,6 +69,8 @@ extern char tuple_lua[]; /* Lua source */ > > > > uint32_t CTID_STRUCT_TUPLE_REF; > > > > +int luaT_tuple_encode_table_ref = LUA_NOREF; > > 2. Better make it static. It is not used outside of this file. Thanks! > > static char * > > luaT_tuple_encode_on_lua_ibuf(struct lua_State *L, int idx, > > size_t *tuple_len_ptr) > > { > > - if (idx != 0 && !lua_istable(L, idx) && !luaT_istuple(L, idx)) { > > + assert(idx != 0); > > + if (!lua_istable(L, idx) && !luaT_istuple(L, idx)) { > > diag_set(IllegalParams, "A tuple or a table expected, got %s", > > lua_typename(L, lua_type(L, idx))); > > return NULL; > > } > > > > - struct ibuf *buf = tarantool_lua_ibuf; > > - ibuf_reset(buf); > > - struct mpstream stream; > > - mpstream_init(&stream, buf, ibuf_reserve_cb, ibuf_alloc_cb, > > - luamp_error, L); > > - if (idx == 0) { > > - /* > > - * Create the tuple from lua stack > > - * objects. > > - */ > > - int argc = lua_gettop(L); > > - mpstream_encode_array(&stream, argc); > > - for (int k = 1; k <= argc; ++k) { > > - luamp_encode(L, luaL_msgpack_default, NULL, &stream, k); > > - } > > - } else { > > - /* Create the tuple from a Lua table. */ > > - luamp_encode_tuple(L, &tuple_serializer, &stream, idx); > > - } > > - mpstream_flush(&stream); > > + int top = lua_gettop(L); > > + > > + /* Calculate absolute value in the stack. */ > > + if (idx < 0) > > + idx = top + idx + 1;> + > > + assert(luaT_tuple_encode_table_ref != LUA_NOREF); > > + lua_rawgeti(L, LUA_REGISTRYINDEX, luaT_tuple_encode_table_ref); > > + assert(lua_isfunction(L, -1)); > > + > > + lua_pushvalue(L, idx); > > + > > + int rc = luaT_call(L, 1, 0); > > + lua_settop(L, top); > > + if (rc != 0) > > + return NULL; > > + > > if (tuple_len_ptr != NULL) > > - *tuple_len_ptr = ibuf_used(buf); > > - return buf->buf; > > + *tuple_len_ptr = ibuf_used(tarantool_lua_ibuf); > > 3. Since you assume the function at luaT_tuple_encode_table_ref alwaus > uses ibuf, maybe it would be better to add 'on_lua_ibuf' to its name. The next commit passes mpstream initialization function to it and I want to avoid double renaming to make diffs more readable. > Or move the length calculation out of the current function, because > this one already has 'on_lua_ibuf', so it wouldn't look so strange to > get size of tarantool_lua_ibuf after it. Don't get a purpose of the proposed changes. Anyway, for defense of given variant, the next commit adds luaT_tuple_encode() with quite similar behaviour and signature and it looks nice, when those functions are virtually same, but based on top of different allocators. > > @@ -156,15 +198,30 @@ lbox_tuple_new(lua_State *L) > > lua_newtable(L); /* create an empty tuple */ > > ++argc; > > } > > + > > + box_tuple_format_t *fmt = box_tuple_format_default(); > > + > > 4. You could keep it after the comment below to reduce the diff. Heh. Good spot. I'll do. > > /* > > * Use backward-compatible parameters format: > > - * box.tuple.new(1, 2, 3) (idx == 0), or the new one: > > - * box.tuple.new({1, 2, 3}) (idx == 1). > > + * box.tuple.new(1, 2, 3). > > */ > > - int idx = argc == 1 && (lua_istable(L, 1) || > > - luaT_istuple(L, 1)); > > - box_tuple_format_t *fmt = box_tuple_format_default(); > > - struct tuple *tuple = luaT_tuple_new(L, idx, fmt); > > + if (argc != 1 || (!lua_istable(L, 1) && !luaT_istuple(L, 1))) { > > + struct ibuf *buf = tarantool_lua_ibuf; > > + luaT_tuple_encode_values(L); /* may raise */ > > 5. We usually put comments on separate line. | /* May raise. */ | luaT_tuple_encode_values(L); ...would make unclear whether it applies to just next call or several ones. We can wrap the call and the comment with empty lines above and below, but it is too much for such small thing. Or we can explicitly point to the call in the comment: | /* The next call may raise. */ | luaT_tuple_encode_values(L); However such comment sometimes displaced by inaccurate commits and befomes useless. So we should mention the function name explicitly, but it, in turn, looks too tautological. I'm aware about the convention, but I still think that one-two word remarks are complelety okay to be placed inline. I don't exploit this much. I'll change it somehow, if it disturbs (and you'll highlight it), but personally I think it is okay.