[Tarantool-patches] [PATCH] Move txn from shema to a separate module (use C API instead of FFI)

[Konstantin Osipov]

* Igor Munkin <imun at tarantool.org> [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