From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp29.i.mail.ru (smtp29.i.mail.ru [94.100.177.89]) (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 4E4AA469719 for ; Thu, 12 Mar 2020 18:42:34 +0300 (MSK) References: <20200306163416.95494-1-olegrok@tarantool.org> <4a346413-08ff-fac6-fe4f-b3ea3e5566a6@tarantool.org> <5bdbe384-5bad-65bf-d54b-74896d68faa6@tarantool.org> From: Oleg Babin Message-ID: <93dabcdb-313a-c911-b1a1-d87af0fb905c@tarantool.org> Date: Thu, 12 Mar 2020 18:42:32 +0300 MIME-Version: 1.0 In-Reply-To: <5bdbe384-5bad-65bf-d54b-74896d68faa6@tarantool.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Subject: Re: [Tarantool-patches] [PATCH] box: introduce "current" for sequence List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladislav Shpilevoy , tarantool-patches@dev.tarantool.org, korablev@tarantool.org Thanks for comments! On 11/03/2020 01:49, Vladislav Shpilevoy wrote: > Here you said, that Tarantool has no sessions, but it is not so. We > have sessions, and even some session local things such as settings, > storage. > It was a cite from https://github.com/tarantool/tarantool/commit/3ff1f1e36e14381c0ebb5862943d4da281254767: | In contrast to PostgreSQL, this method doesn't make sense in | Tarantool, because we don't have sessions. It was said before _session_storage was implemented but box.session has been already existed. I will try to drop this misleading statement and add: `In contrast "current" returns the last globally retrieved value of the sequence`. Ok? > FFI has nothing to do with contracts. It is about performance. > We don't have a rule, that a whole subsystem should be either > completely in FFI, or completely in Lua C. Lots of things are > implemented in FFI + Lua C + Lua. For example, fiber module - > it uses all the 3 ways simultaneously. box_select() is FFI for > memtx, is Lua C for vinyl, and so on. > > On the contrary, we have a rule to make things via FFI when it > is possible (there was a discussion about that recently, don't > know whether it was formalized anywhere). > > Also I don't see any reason to make it FFI in a separate patch. > Why not in this one? What is a purpose of introducing a function > and re-implementing it right in a next patch and even create an > issue for that? > > The most reasonable split I see here is to introduce the C > function in one patch, and FFI in Lua in a second patch. In > scope of one patchset. As we can use FFI for all functions that doesn't yield, we can rewrite e.g. "next" with FFI as well. It will be a bit more uniformly. And the idea is to do it in separate patch. But ok, I'll change "current" from Lua C API to FFI and send new patch. -- Oleg Babin