[Tarantool-patches] [PATCH 1/1] box: export box_session_push to the public C API

[Alexander Turenko]

On Thu, Jan 23, 2020 at 12:05:02AM +0100, Vladislav Shpilevoy wrote:
> On 22/01/2020 03:25, Alexander Turenko wrote:
> >>> I see that box_return_tuple() receives (box_function_ctx_t *) as the
> >>> first argument and wonder why box_session_push() does not. If we able to
> >>> determine where to and how to send a push w/o the context, then the
> >>> context is not necessary in box_return_tuple() too? I don't very
> >>> familiar with this part of codebase, so it is just question for now.
> >>> I'll look around soon if time permits.
> >>
> >> Context of session push is a session. It is available in fiber, which
> >> is a global variable.
> >>
> >> Context of a function is its port - a storage for returned values. Port
> >> is not available in the fiber, and therefore is not stored anywhere
> >> globally. It needs to be passed explicitly. We pass it as an opaque
> >> pointer box_function_ctx_t*.
> >>
> >> We can add a context to the push, but then we need to create a public
> >> version of struct session. Something like 'box_session_t', which would
> >> be an alias for 'struct session'. And have a function like
> >> 'box_session_current()', which in turn won't have a context.
> >>
> >> I think we need to introduce box_session_t only if we are going to
> >> allow users to access foreign sessions. Otherwise it is always the
> >> user's own session and is available in the fiber anyway.
> > 
> > But box_return_tuple() can create a port on demand, just like you do in
> > box_session_push(), right? I don't see any difference between those
> > functions in context of the question.
> > 
> > If box_return_tuple() could be implemented with or without explicit
> > (box_function_ctx_t *) argument in the past, then someone made the
> > decision to implement it with the argument and there is (hopefully) some
> > reasoning under this decision. If so, it may be applicable to
> > box_session_push(). Or there is a reason why it is not applicable here.
> 
> Well, I recommend you to look at the code and think about it. You can't
> create a port on demand in box_return_tuple(). Because where would you
> put it then? box_return_tuple()'s context is a link to the stack frame
> called the user's function, where the port is stored. You can't omit it
> in box_return_tuple(). There is just no way. By the same reason SQL
> functions have sql_context and pass it to sql_result_*(). And this is
> why box_function_ctx_t* is an opaque pointer, which can't be created by
> a user. It is created by us for the user.
> 
> The only way to avoid passing a context is to always return a result
> using 'return' statement. In that case you return directly to the
> caller. But it does not allow to do multireturn, and to do something
> after return. For these cases you need a context. And this is our case
> with box_return_tuple().
> 
> In box_session_push() you don't need an upper stack frame or whatever
> else what is not available in the fiber. And you don't have any special
> caller's context. Push() does not return to anywhere. It pushes out of
> bound.
> 
> I don't know how to explain this else.

Igor engaged me to discuss it and now I understand the idea. I'll
summarize it below (just in case).

Now I understood the difference you told me about. An usual return value
is transferred **to a caller**, which may be a Lua function, binary
protocol client, SQL VDBE, functional index. A session push value is
transferred directly to a 'client' that started the session over all
calling chain.

The example that illustrates this: a binary protocol client calls a Lua
function 'foo', which calls a Lua function 'bar', which performs pushes
to a session. Those pushes are transferred directly to the binary
procotol client.

The nature of 'session push' action is such that it does not need
box_function_ctx_t*, which in fact is the bridge to a caller.

WBR, Alexander Turenko.