From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp57.i.mail.ru (smtp57.i.mail.ru [217.69.128.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id AEA334696C3 for ; Tue, 7 Apr 2020 02:40:23 +0300 (MSK) Date: Tue, 7 Apr 2020 02:40:24 +0300 From: Alexander Turenko Message-ID: <20200406234024.r3nyhoflaswdcsoi@tkn_work_nb> References: <1065f691482e681b779abd3698ec4489267c11fd.1579558507.git.v.shpilevoy@tarantool.org> <20200121002441.sysri34odzjrpjzu@tkn_work_nb> <20200122022537.tygaowsn5remjee4@tkn_work_nb> <5925f9e8-e148-9d68-eb39-db87e9e631eb@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5925f9e8-e148-9d68-eb39-db87e9e631eb@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH 1/1] box: export box_session_push to the public C API List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladislav Shpilevoy Cc: tarantool-patches@dev.tarantool.org 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.