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 1950C316CB for ; Fri, 21 Jun 2019 18:31:15 -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 3Pz5b_ofYPkk for ; Fri, 21 Jun 2019 18:31:15 -0400 (EDT) Received: from smtp56.i.mail.ru (smtp56.i.mail.ru [217.69.128.36]) (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 C48CD315D1 for ; Fri, 21 Jun 2019 18:31:14 -0400 (EDT) Date: Sat, 22 Jun 2019 01:31:12 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [PATCH 2/2] swim: introduce generation Message-ID: <20190621223112.GA7915@atlas> References: <9852675764d25bdc720023ed6763d97cbeab8bee.1561065646.git.v.shpilevoy@tarantool.org> <20190621065358.GF18958@atlas> <9a45ac3e-0bf7-6aad-e673-494c1e20a8da@tarantool.org> <20190621194843.GB28557@atlas> <20190621195326.GC28557@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Vladislav Shpilevoy Cc: tarantool-patches@freelists.org * Vladislav Shpilevoy [19/06/22 01:03]: Yup. > We have decided in a chat, that a user should be > able to get separately 'generation', 'version', and > accumulated 'incarnation' as a binary merge of these > two values. It allows in simple cases do not care > about generation/version, and stick to the incarnation > only. > > Concerning API. I suggest the following C API changes: > > - uint64_t > - swim_member_incarnation(const struct swim_member *member); > > + struct swim_incarnation { > + uint64_t generation; > + uint64_t version; > + }; > + > + int > + swim_incarnation_cmp(const struct swim_incarnation *l, > + const struct swim_incarnation *r); > + > + struct swim_incarnation > + swim_member_incarnation(const struct swim_member *member); > > struct swim_incarnation will be a public structure in order to > simplify working with C API. I am trying to avoid returning some > const char * or similarly abstract thing. > > > > Lua API changes are different. I know, we've talked about > returning a binary string as an incarnation, but then we need > separate methods to take version and generation, and waste > memory on these temporary binary strings, useless for anything > but comparison. Worse, we will desync with C API. > > > I've found a revolutionary feature of Lua FFI which can help us > very much. It combines your 'merged' incarnation, and my 'totally > different numbers' incarnation. In Lua FFI you can define your > own comparison operators for C structs (just learned about that)! > > Method member:incarnation() will return cdata struct swim_incarnation, > with ffi.metatype containing comparators. struct swim_incarnation > will be initialized in Lua like this: > > > ffi = require('ffi') > ffi.cdef[[ > struct swim_incarnation { > uint64_t generation; > uint64_t version; > }; > ]] > inc_t = ffi.typeof('struct swim_incarnation') > inc_mt = { > __eq = function(l, r) > return l.generation == r.generation and > l.version == r.version > end, > __lt = function(l, r) > return l.generation < r.generation or > l.generation == r.generation and l.version < r.version > end, > __le = function(l, r) > return l.generation < r.generation or > l.generation == r.generation and l.version <= r.version > end, > } > ffi.metatype(inc_t, inc_mt) > ia = ffi.new('struct swim_incarnation') > ib = ffi.new('struct swim_incarnation') > > ia and ib can be compared using just '< > <= >= == ~=' operators, > and at the same time you can access individual members!!! > > What do you think? Both about C and Lua API changes. -- Konstantin Osipov, Moscow, Russia