Tarantool development patches archive
 help / color / mirror / Atom feed
From: Alexander Turenko <alexander.turenko@tarantool.org>
To: Leonid Vasiliev <lvasiliev@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org,
	Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Subject: Re: [Tarantool-patches] [PATCH 0/6] Extending error functionality
Date: Wed, 1 Apr 2020 18:35:35 +0300	[thread overview]
Message-ID: <20200401153535.uk7olbxabip3os52@tkn_work_nb> (raw)
In-Reply-To: <cover.1585053742.git.lvasiliev@tarantool.org>

We discussed several questions around the API and the implementation
yesterday with Leonid and Vlad. Vlad summarized the API points in the
issue (see [1]). I want to summarize implementation details we
more-or-less agreed on.

We have two places, where encoding and decoding is performed to/from
msgpack: they are src/lua/{msgpack.c,msgpackffi.lua}.

I propose to add two mappings to msgpack.c:

 | /*
 |  * Encode an object on @an idx slot on the Lua stack into
 |  * @a buf, promote @a buf pointer on written bytes amount.
 |  *
 |  * Don't write over @an end pointer (inclusive).
 |  */
 | typedef void (*encode_ext_f)(struct lua_State *L, int idx, char **buf,
 |                              char *end);
 |
 | /*
 |  * Decode msgpack from @buf, push it onto the Lua stack.
 |  *
 |  * Promote @a buf on amount of read bytes.
 |  *
 |  * Don't read over @an end (inclusive).
 |  *
 |  */
 | typedef void (*decode_ext_f)(struct lua_State *L, char **buf, char *end);
 |
 | /* cdata type id -> encode function */
 | static mh_encode_ext;
 |
 | /* msgpack extension type -> decode function */
 | static mh_decode_ext;
 |
 | /* Register encode function for a cdata type. */
 | void
 | register_encode_ext(int ctypeid, encode_ext_f f);
 |
 | /* Register decode function for an extension type. */
 | void
 | register_decode_ext(int mp_ext_type, decode_ext_f f);

So box will add its own encode / decode functions for box.error objects
on box initialization (at tarantool loading, not at box.cfg()). The
problem we'll solve here is that src/lua/msgpack.c should not be
statically linked with src/box.

The similar change should be made for msgpackffi.lua. It, however,
already has `encode_ext_cdata` and `ext_decoder` tables. So it seems we
just need to add registration functions.

Note: Don't sure whether encode_ext / decode_ext should operate directly on
the Lua stack or we should separate those functions into get_from_stack+encode
and decode+push_to_stack. (Vlad?)

The functions that will be exposed by box should encode any box.error
object into msgpack and decode any msgpacked box.error into box.error
object.  Build*Error() constructors should be called for this with
appropriate arguments. So the decode function will contain the switch by
an error types and call necessary Build*Error() functions. Maybe also
will replace the error message, where needed.

This way looks hacky, but at least it concentrates hacking in one place.
When we'll remove C++ classes for errors, we can refactor this part.

[1]: https://github.com/tarantool/tarantool/issues/4398#issuecomment-606937494

WBR, Alexander Turenko.

      parent reply	other threads:[~2020-04-01 15:35 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-24 12:45 Leonid Vasiliev
2020-03-24 12:45 ` [Tarantool-patches] [PATCH 1/6] error: Add a Lua backtrace to error Leonid Vasiliev
2020-04-05 22:14   ` Vladislav Shpilevoy
2020-04-08 13:56     ` Igor Munkin
2020-03-24 12:46 ` [Tarantool-patches] [PATCH 2/6] error: Add the custom error type Leonid Vasiliev
2020-04-05 22:14   ` Vladislav Shpilevoy
2020-03-24 12:46 ` [Tarantool-patches] [PATCH 3/6] iproto: Add negotiation phase Leonid Vasiliev
2020-03-24 20:02   ` Konstantin Osipov
2020-03-25  7:35     ` lvasiliev
2020-03-25  8:42       ` Konstantin Osipov
2020-03-25 10:56         ` Eugene Leonovich
2020-03-25 11:13           ` Konstantin Osipov
2020-03-26 11:37           ` lvasiliev
2020-03-26 11:18         ` lvasiliev
2020-03-26 12:16           ` Konstantin Osipov
2020-03-26 12:54             ` Kirill Yukhin
2020-03-26 13:19               ` Konstantin Osipov
2020-03-26 13:31                 ` Konstantin Osipov
2020-03-26 21:13       ` Alexander Turenko
2020-03-26 21:53         ` Alexander Turenko
2020-03-27  8:28         ` Konstantin Osipov
2020-03-26 23:35       ` Alexander Turenko
2020-03-27  8:39         ` Konstantin Osipov
2020-03-24 12:46 ` [Tarantool-patches] [PATCH 4/6] error: Add extended error transfer format Leonid Vasiliev
2020-03-24 12:46 ` [Tarantool-patches] [PATCH 5/6] error: Add test for extended error Leonid Vasiliev
2020-03-24 12:46 ` [Tarantool-patches] [PATCH 6/6] error: Transmit an error through IPROTO_OK as object Leonid Vasiliev
2020-03-27 23:11 ` [Tarantool-patches] [PATCH 0/6] Extending error functionality lvasiliev
2020-03-28 13:54   ` Alexander Turenko
2020-03-30 10:48     ` lvasiliev
2020-04-01 15:35 ` Alexander Turenko [this message]

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=20200401153535.uk7olbxabip3os52@tkn_work_nb \
    --to=alexander.turenko@tarantool.org \
    --cc=lvasiliev@tarantool.org \
    --cc=tarantool-patches@dev.tarantool.org \
    --cc=v.shpilevoy@tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH 0/6] Extending error functionality' \
    /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