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 68CA2469719 for ; Fri, 13 Mar 2020 00:09:57 +0300 (MSK) References: <20200306163416.95494-1-olegrok@tarantool.org> <4a346413-08ff-fac6-fe4f-b3ea3e5566a6@tarantool.org> <5bdbe384-5bad-65bf-d54b-74896d68faa6@tarantool.org> <93dabcdb-313a-c911-b1a1-d87af0fb905c@tarantool.org> From: Vladislav Shpilevoy Message-ID: Date: Thu, 12 Mar 2020 22:09:55 +0100 MIME-Version: 1.0 In-Reply-To: <93dabcdb-313a-c911-b1a1-d87af0fb905c@tarantool.org> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit 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: Oleg Babin , tarantool-patches@dev.tarantool.org, korablev@tarantool.org On 12/03/2020 16:42, Oleg Babin wrote: > 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? I don't know why was it said back then that we don't have sessions. Maybe Vova meant we don't have exactly the same sessions as PostgreSQL, with full isolation and so on. >> 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. It is not possible. Because sequence_next() can be used only via box_sequence_next() by the public API. And box_sequence_next() can yield. Box_sequence_set/reset/next() - all of them can yield. > -- > Oleg Babin