From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com [209.85.208.196]) (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 660E54696C2 for ; Fri, 29 Nov 2019 12:09:34 +0300 (MSK) Received: by mail-lj1-f196.google.com with SMTP id u17so3797859lja.4 for ; Fri, 29 Nov 2019 01:09:34 -0800 (PST) Date: Fri, 29 Nov 2019 08:30:59 +0300 From: Konstantin Osipov Message-ID: <20191129053059.GE15149@atlas> References: <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> <20191128155801.GB11584@atlas> <20191128183615.GC1214@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191128183615.GC1214@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 21:39]: > > 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. > > Unfortunately, I haven't seen the thread where the subj is discussed > with Mike Pall, but the approach you proposed doesn't seem to be a > convenient one, however it still solves a problem (as does the move to > use Lua-C API for the code with possible Lua VM re-entrance underneath). > > The major flaw I see in this solution, is introducing the dependency on > the JIT interface into Tarantool internals. There is already one > dependency on LuaJIT-2.1.0 presented with internal headers usage for > several hacks in utils.c. As a result we are not able to simply replace > the Lua implementation to try another one (e.g. uJIT conforming > LuaJIT-2.0.5) for comparing each other. Well, this is not exactly a flaw of the solution, then: it would have been a flaw if we had a choice - whether to introduce a dependency or not. The dependency is already there, with its costs. When we introduced the dependency it was not an arbitrary decision either: the strategy has always been that Tarantool will become bigger & stronger and will have its own JIT team, so we will be able to sustain the costs of tight coupling. This strategy has partly materialized with you and Sergos on board of MRG team. Now it's a matter of you guys being bold enough to take one step further and integrate LuaJIT with tarantool fibers. I know of no good reason why yields break traces, and if they stop doing that, we can switch everything to FFI. This is of course outside the scope of this patch, but is related to the policy for FFI vs Lua/C. -- Konstantin Osipov, Moscow, Russia