From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id 170C86EC40; Fri, 13 Aug 2021 13:01:49 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 170C86EC40 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1628848909; bh=dpNPC0R5ZO3FVLVoxdvZBY5XCeohT8dwRWkQXdM49oc=; h=Date:To:Cc:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=LJANypYiGrws7nYkT1MNbLUE8Jj/XBAtlLyr9hywDElivjeR3fR/YsUvwUsRbQiSO ZMf7WXpCQMgb0ge7q5huhyvW6ui/1MqcrbXFHNwC9fNcqNXdIErjyeIZbmz1RHXli/ zpvSBXlu/GBGGDdLEE1umUktERlDH9tTbbUJU48k= Received: from smtpng1.i.mail.ru (smtpng1.i.mail.ru [94.100.181.251]) (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 65EE06EC40 for ; Fri, 13 Aug 2021 13:01:48 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 65EE06EC40 Received: by smtpng1.m.smailru.net with esmtpa (envelope-from ) id 1mEU0Z-0004f8-P3; Fri, 13 Aug 2021 13:01:48 +0300 Date: Fri, 13 Aug 2021 13:01:46 +0300 To: Vladislav Shpilevoy Cc: tarantool-patches@dev.tarantool.org Message-ID: <20210813100146.s7fvpw47hmczfer5@esperanza> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-4EC0790: 10 X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD92087353F0EC44DD910164DC12A5633065676A9727AC27C74182A05F538085040123C73CB79641A6B3FF9E47ECBCC4C326A7308DA67077E4C0564F704BA246426 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE72E4E5201E1C2E308EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006371A8529349DFA27258638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D80FDD78DED793BCE9A599D31C8F6EC64F117882F4460429724CE54428C33FAD305F5C1EE8F4F765FCF1175FABE1C0F9B6A471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F446042972877693876707352033AC447995A7AD18618001F51B5FD3F9D2E47CDBA5A96583BA9C0B312567BB231DD303D21008E29813377AFFFEAFD269A417C69337E82CC2E827F84554CEF50127C277FBC8AE2E8BA83251EDC214901ED5E8D9A59859A8B613439FA09F3DCB32089D37D7C0E48F6C5571747095F342E88FB05168BE4CE3AF X-C1DE0DAB: 0D63561A33F958A51323A340DD0BFC556585956617B4FCD757231DC2263D7E3ED59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA750E14360347543F58410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D34F8A2DF183797A6A817E75ECA8F0BAA2B5A37D7B4E8966FDC106FC558BEC8B60657188C7AD1D6DF241D7E09C32AA3244CCA01E18E11A9E2F951025C89EA19957B6C24832127668422FACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2bioj0dLV0c3jbkwkYb78QLxYxA== X-Mailru-Sender: 689FA8AB762F7393C37E3C1AEC41BA5DE6DA121E2C1F3C3DA45C435993265252274CEFED1673C562683ABF942079399BFB559BB5D741EB966A65DFF43FF7BE03240331F90058701C67EA787935ED9F1B X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH] net.box: allow to store user-defined fields in future object X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Vladimir Davydov via Tarantool-patches Reply-To: Vladimir Davydov Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" On Thu, Aug 12, 2021 at 09:02:46PM +0300, Vladislav Shpilevoy wrote: > > + > > +static int > > +luaT_netbox_request_newindex(struct lua_State *L) > > +{ > > + struct netbox_request *request = luaT_check_netbox_request(L, 1); > > + struct mh_strnptr_t *h = request->index; > > + size_t field_name_len; > > + const char *field_name = lua_tolstring(L, 2, &field_name_len); > > + if (field_name == NULL) > > + return luaL_error(L, "invalid index"); > > + int field_value_ref = luaL_ref(L, LUA_REGISTRYINDEX); > > + if (field_value_ref == LUA_REFNIL) { > > + /* The field is set to nil. Delete it from the index. */ > > 1. But it is not deleted. It is just ignored, which is fine, but > the comment is wrong then. > > > + if (h == NULL) > > + return 0; > > + mh_int_t k = mh_strnptr_find_inp(h, field_name, > > + field_name_len); > > + int ref = (intptr_t)mh_strnptr_node(h, k)->val; > > + luaL_unref(L, LUA_REGISTRYINDEX, ref); > > + mh_strnptr_del(h, k, NULL); > > + return 0; > > + } > > + if (h == NULL) { > > + /* Lazily create the index on the first invocation. */ > > + h = request->index = mh_strnptr_new(); > > + if (h == NULL) { > > + luaL_unref(L, LUA_REGISTRYINDEX, field_value_ref); > > + return luaL_error(L, "out of memory"); > > + } > > + } > > + /* Insert a reference to the new value into the index. */ > > + struct mh_strnptr_node_t node = { > > + .str = field_name, > > + .len = field_name_len, > > + .hash = mh_strn_hash(field_name, field_name_len), > > 2. lua_hashstring() might be faster. You could reuse already > calculated hash value from Lua. Although for that 'field_name' > must be of exactly string type (lua_tolstring() works not only for > strings). So if you would make a more precise type check, you > could avoid hash calculation completely. Or use lua_hash() for > non-string values' strings. (But I might be wrong about how > lua_hashstring() works for non-string values, you would need to > double-check). > > > + .val = (void *)(intptr_t)field_value_ref, > > 3. Can you simply cast to void * right away? Why do you need the > intermediate intptr_t cast? I reworked the patch to use a Lua table instead of mhash, as per the suggestion by imun@, so these comments are not relevant anymore. Please see v3: https://lists.tarantool.org/pipermail/tarantool-patches/2021-August/025458.html