Tarantool development patches archive
 help / color / mirror / Atom feed
From: Alexander Turenko <alexander.turenko@tarantool.org>
To: Leonid <lvasiliev@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [PATCH] Move txn from shema to a separate module (use C API instead of FFI)
Date: Thu, 12 Dec 2019 01:21:35 +0300	[thread overview]
Message-ID: <20191211222134.swzcqcbpn4tbg64m@tkn_work_nb> (raw)
In-Reply-To: <156ce93b495648d6f3fd6c879b0d9aaf56754a1e.1574773773.git.lvasiliev@tarantool.org>

Kostya, thanks for bringing the FFI / Lua-C question into our view.

----

We decided to don't change existing convention: let's use FFI when
possible and Lua-C API for functions that access a Lua state somehow
(including touching tarantool_L, yielding and running triggers /
callbacks).

The core reason is that FFI allows to produce longer JIT traces that
should positively impact performance of an application at whole.

We have no good understanding how performant Lua-C API with trace
stitching, however simple benchmarks (shared by Leonid) shows positive
impact of using FFI calls.

We have no interpretation for those benchmarks for now. Whether Lua-C
runs were JITed at all? Whether a result will be different if there will
be more JITable code around? So for now things looks just as 'FFI is
faster the Lua-C'. Hope we'll investigate this later.

We need to find a way to reduce probability that a function that is
called via ffi (or one that is called from it) will be changed in a
future and starts to yield or touch a Lua state.

We should look whether we can mark functions that are called from ffi
(see also [1]) and all its callee to at least verify ourself when
changing code.

Also we can work on detection of so called ffi sandwitches and doing
more stress testing.

It seems that both directions are worth to dig into.

[1]: https://github.com/tarantool/tarantool/issues/4202

----

Back to the patch.

Since we'll just move one function, I would not perform refactoring I
proposed initially: don't move all related functions together. Let's
rewrite box.rollback_to_savepoint() using Lua-C API and place it together
with box.commit() and box.rollback() to src/box/lua/init.c.

I think we don't need any pure Lua wrapper around this function: we can
access a Lua table field and raise an error just from C, so I don't see
a reason to split a function logic around two files
(src/box/lua/schema.lua and src/box/lua/init.c). They are both about API
we expose to Lua.

WBR, Alexander Turenko.

On Tue, Nov 26, 2019 at 04:13:43PM +0300, Leonid wrote:
> https://github.com/tarantool/tarantool/issues/4427
> https://github.com/tarantool/tarantool/tree/lvasiliev/gh-4427-move-some-stuff-from-ffi-to-c-api
> 
> ---
>  src/box/CMakeLists.txt       |   2 +
>  src/box/lua/init.c           |   4 +
>  src/box/lua/schema.lua       |  71 -----------------
>  src/box/lua/txn.c            | 145 +++++++++++++++++++++++++++++++++++
>  src/box/lua/txn.h            |  49 ++++++++++++
>  src/box/lua/txn.lua          |  53 +++++++++++++
>  src/box/txn.c                |   2 +
>  test/box/misc.result         |   1 +
>  test/engine/savepoint.result |  12 +--
>  9 files changed, 262 insertions(+), 77 deletions(-)
>  create mode 100644 src/box/lua/txn.c
>  create mode 100644 src/box/lua/txn.h
>  create mode 100644 src/box/lua/txn.lua

> --- box.commit yields, so it's defined as Lua/C binding
> --- box.rollback yields as well

Let's move box.rollback_to_savepoint() to them.

  parent reply	other threads:[~2019-12-11 22:21 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-26 13:13 Leonid
2019-11-26 21:05 ` Konstantin Osipov
2019-11-26 21:17   ` Alexander Turenko
2019-11-27  8:31     ` Konstantin Osipov
2019-11-28  8:10       ` Leonid Vasiliev
2019-11-28 12:34         ` Konstantin Osipov
2019-11-28 13:00           ` Igor Munkin
2019-11-28 13:18             ` Konstantin Osipov
2019-11-28 14:03               ` Igor Munkin
2019-11-28 15:58                 ` Konstantin Osipov
2019-11-28 18:36                   ` Igor Munkin
2019-11-29  5:30                     ` Konstantin Osipov
2019-11-29 17:43                       ` Igor Munkin
2019-11-29  5:41                     ` Konstantin Osipov
2019-11-29 17:37                       ` Igor Munkin
2019-12-04 13:05                     ` Leonid Vasiliev
2019-12-04 13:15                       ` Konstantin Osipov
2019-12-05  8:27                         ` Leonid Vasiliev
2020-03-20 18:48               ` Igor Munkin
2020-03-20 19:27                 ` Konstantin Osipov
2019-12-11 22:21 ` Alexander Turenko [this message]
2019-12-12  8:23   ` Leonid Vasiliev
2020-01-15 17:05     ` Alexander Turenko
2019-12-12  8:49   ` Konstantin Osipov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191211222134.swzcqcbpn4tbg64m@tkn_work_nb \
    --to=alexander.turenko@tarantool.org \
    --cc=lvasiliev@tarantool.org \
    --cc=tarantool-patches@dev.tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH] Move txn from shema to a separate module (use C API instead of FFI)' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox