Re: [tarantool-patches] Re: [PATCH v3 2/6] box: rework box_lua_{call, eval} to use input port

[Kirill Shcherbatov <kshcherbatov@tarantool.org>]

On 20.06.2019 11:09, Konstantin Osipov wrote:
> * Kirill Shcherbatov <kshcherbatov@tarantool.org> [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.
	/**
	 * 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. The is_flat == true mode
	 * follows Lua functions convention to pass arguments
	 * and return a results, while is_flat == false follows
	 * Tarantool's :select convention when the table of
	 * results is returned.
	 */
	void (*dump_lua)(struct port *port, struct lua_State *L, bool is_flat);
	

> 
>> 	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);
	/**
	 * Get the content of a port as a msgpack data.
	 * By an obsolete convention, C stored routines expect
	 * msgpack data as input format for its arguments.
	 * This API is also usefull to process a function
	 * returned value as msgpack data in memory.
	 * 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.
	 **/
	const char *(*get_msgpack)(struct port *port, uint32_t *size);