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 EE1AE31647 for ; Fri, 21 Jun 2019 17:59:50 -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 yJULdkMxTIfG for ; Fri, 21 Jun 2019 17:59:50 -0400 (EDT) Received: from smtp50.i.mail.ru (smtp50.i.mail.ru [94.100.177.110]) (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 A4AEE31645 for ; Fri, 21 Jun 2019 17:59:50 -0400 (EDT) Subject: [tarantool-patches] Re: [PATCH 2/2] swim: introduce generation References: <9852675764d25bdc720023ed6763d97cbeab8bee.1561065646.git.v.shpilevoy@tarantool.org> <20190621065358.GF18958@atlas> <9a45ac3e-0bf7-6aad-e673-494c1e20a8da@tarantool.org> <20190621194843.GB28557@atlas> <20190621195326.GC28557@atlas> From: Vladislav Shpilevoy Message-ID: Date: Sat, 22 Jun 2019 00:00:23 +0200 MIME-Version: 1.0 In-Reply-To: <20190621195326.GC28557@atlas> Content-Type: text/plain; charset=utf-8 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: Konstantin Osipov Cc: tarantool-patches@freelists.org 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.