From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-f68.google.com (mail-lf1-f68.google.com [209.85.167.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 1F41F46970F for ; Thu, 28 Nov 2019 18:58:03 +0300 (MSK) Received: by mail-lf1-f68.google.com with SMTP id d6so20420648lfc.0 for ; Thu, 28 Nov 2019 07:58:03 -0800 (PST) Date: Thu, 28 Nov 2019 18:58:01 +0300 From: Konstantin Osipov Message-ID: <20191128155801.GB11584@atlas> References: <156ce93b495648d6f3fd6c879b0d9aaf56754a1e.1574773773.git.lvasiliev@tarantool.org> <20191126210520.GE23422@atlas> <20191126211701.mhavpytwkemux3vm@tkn_work_nb> <20191127083123.GA2752@atlas> <20191128123445.GC29714@atlas> <20191128130005.GA1214@tarantool.org> <20191128131804.GE29714@atlas> <20191128140340.GB1214@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191128140340.GB1214@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH] Move txn from shema to a separate module (use C API instead of FFI) List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Munkin Cc: tarantool-patches@dev.tarantool.org * Igor Munkin [19/11/28 17:08]: > Why should we be aiming at using FFI more? The root cause is that > current fiber machinery (as well as some parts of triggers mechanism) > doesn't respect the Lua coroutine switch semantics, thereby breaking > trace recording. Lua-C API implicitly (or non-intentionally) prevents > breakage by JIT trace aborts when recording FUNCC. It's not correct. The current FFI functions were carefully crafted to never lead to sandwich code: only those functions which can not trigger a return to Lua were implemented as FFI. There was one regression between 1.10 and in 2.3 because we started firing rollback triggers when rolling back to a savepoint, which was spotted by a failing tests. One more time: When FFI bindings were written we were aware of NYI and took it into account. > Therefore, I guess we should be aiming either at changing fiber > switching to the one respecting the LuaJIT runtime or at tuning JIT > compiler way more regarding the Lua-C usage. This is actually quite simple - we could easily call a LuaJIT hook whenever switching a fiber, to make sure that it carefully switches the internals as well. Mike Pall refused to cooperate on the matter, but now we (you) control our own destiny. > Besides, we can't fully prevent platform failures if there is an FFI > misusage in users code. Tarantool has never been claiming that it prevents people from shooting themselves in the foot. Performance is the ultimate design goal, at the cost of safety at times. > > What should be the rule of thumb in your opinion, ffi or > > lua/c? > > If you want to know my rule of thumb: FFI is for external existing > libraries to be used in Lua code (and all compiler related benefits are > nothing more than a godsend consequence, since all guest stack > manipulations are implemented in LuaJIT runtime, not in an external > code) and Lua-C is a well-designed and well-documented API for embedding > Lua into a host application / extending Lua with external low-lewel > libs. I totally do not insist on my point of view, since everyone has > it's own vision on LuaJIT features. OK, but there must be a single policy though. So far it was: everything that doesn't yield and doesn't call back to Lua uses FFI. Everything else *has* to use Lua/C API, UNTIL there is a way to safely sandwich FFI calls. -- Konstantin Osipov, Moscow, Russia