From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 84EFE2C05E for ; Wed, 17 Oct 2018 16:36:59 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WA8NuuKc_RjI for ; Wed, 17 Oct 2018 16:36:59 -0400 (EDT) Received: from smtpng2.m.smailru.net (smtpng2.m.smailru.net [94.100.179.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 31B692C099 for ; Wed, 17 Oct 2018 16:36:58 -0400 (EDT) Subject: [tarantool-patches] Re: [PATCH] box: add tuple:size function References: <1538070923-23087-1-git-send-email-ivushkinalex@gmail.com> <20181016182144.GB5454@chai> <20181017072810.bxyfdrtq2rsxj5ub@tkn_work_nb> <20181017152949.GB19013@chai> <4f41a343-cd2a-44c3-06b8-3267db212b79@tarantool.org> <20181017181447.GC28587@chai> From: Vladislav Shpilevoy Message-ID: <516dab0e-c9d5-5dcd-0984-9d2283b5ff85@tarantool.org> Date: Wed, 17 Oct 2018 23:36:53 +0300 MIME-Version: 1.0 In-Reply-To: <20181017181447.GC28587@chai> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-subscribe: List-owner: List-post: List-archive: To: tarantool-patches@freelists.org, Konstantin Osipov Cc: Alexander Turenko , Morgan-iv On 17/10/2018 21:14, Konstantin Osipov wrote: > * Vladislav Shpilevoy [18/10/17 21:12]: > >> Also, some people can use it right now to allocate a >> buffer of a correct size before calling box_tuple_to_buf. >> I understand, that box_tuple_to_buf(tuple, NULL, 0) returns >> bsize as well, but some people could miss it, or just use >> box_tuple_bsize because it looks better when you write like >> this: >> >> size = box_tuple_bsize(tuple) >> buf = alloc(size) >> box_tuple_to_buf(tuple, buf, size) >> >> than like this: >> >> size = box_tuple_to_buf(tuple, NULL, 0) // <- difference >> buf = alloc(size) >> box_tuple_to_buf(tuple, buf, size) >> >> Even if we close eyes on the fact, that a user of >> the first way will allocate more data than needed, >> imagine, that then he does something like this: >> >> send(sockfd, buf, size) >> >> Now, he send some garbage uninitialized data of 14 >> bytes at the end of buf. > > Is there any known use? > It is a strange question, especially from you. Open source public API's nature is to be assumed as being used right now in a real project. When a product is free and open source, you can not be sure how many users do you have exactly and who uses which API, so you HAVE to assume that each API function is used somewhere in all possible ways. At first, it can be used in some GitHub project as Alexander underlined, in some connectors. At second, not all projects are hosted on GH. Out API can be used in any imaginable proprietary project. As I said, I knew you will not believe me, but if you asked about why somebody needs 'send' in their Tarantool module, I would answer this: * it can be a customer's proxy - he could create own TCP server in front of Tarantool to send/receive tuples with very simplified protocol, easier than IProto, or to just convert to protocol of another DB; * it is not necessary 'send'. It can be 'write' to a disk. For example, Tarantool is an extra light and fast in-memory cache for some non-critical data, that is persisted by user's facilities, or in another DB, having disk storage; * it can be Mons-like weird way to get tuple data without iterating over it via box_tuple_iterator nor copying into buf: const char *tuple_whole_data = box_tuple_field(tuple, 0); size_t tuple_msgpack_size = box_tuple_size(tuple); /* * then use whole range * [tuple_whole_data, tuple_whole_data + tuple_msgpack_size] */ I know that it is illegal way, but it works now, and allows to do not copy data.