From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 20 Jun 2019 11:09:45 +0300 From: Konstantin Osipov Subject: Re: [tarantool-patches] [PATCH v3 2/6] box: rework box_lua_{call, eval} to use input port Message-ID: <20190620080945.GJ15155@atlas> References: <20190619182820.GD6260@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: To: Kirill Shcherbatov Cc: tarantool-patches@freelists.org, vdavydov.dev@gmail.com List-ID: * Kirill Shcherbatov [19/06/20 10:54]: > /** > * Dump the content of a port to a given Lua stack. > * When is_flat == true is specified, the data is dumped > * directly to Lua stack, item-by-item. Otherwise, a > * result table is created. > */ Still I miss why we need this mode from this comment. Is this for 1.6 compatibility? I would ditch it in this case, we are not obliged to support 1.6 in 2.3. > void (*dump_lua)(struct port *port, struct lua_State *L, bool is_flat); > > /** > * Get the content of a port as a msgpack data. > * The lifecycle of the returned value is > * implementation-specific: it may either be returned > * directly from the port, in which case the data will > * stay alive as long as the port is alive, or it may be > * allocated on the fiber()->gc, in which case the caller > * is responsible for cleaning up. > **/ Once again, please also explain how it is going tobe used - by an obsolete convention, C stored routines expect msgpack data as input format for its arguments. > const char *(*get_msgpack)(struct port *port, uint32_t *size); -- Konstantin Osipov, Moscow, Russia