Tarantool development patches archive
 help / color / mirror / Atom feed
From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
To: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: tml <tarantool-patches@dev.tarantool.org>,
	Alexander Turenko <alexander.turenko@tarantool.org>
Subject: Re: [Tarantool-patches] [PATCH v4 5/6] box/func: implement cfunc Lua module
Date: Mon, 5 Oct 2020 23:59:05 +0200	[thread overview]
Message-ID: <d977ed4e-5481-342c-fb19-d64848a956be@tarantool.org> (raw)
In-Reply-To: <20201005103148.GD2069@grain>

Hi! Thanks for the answers!

On 05.10.2020 12:31, Cyrill Gorcunov wrote:
> On Sat, Oct 03, 2020 at 03:55:26PM +0200, Vladislav Shpilevoy wrote:
>> Thanks for the patch!
>>
>> See 20 comments below.
>>
>> On 01.10.2020 15:51, Cyrill Gorcunov wrote:
>>> Currently to run "C" function from some external module
>>> one have to register it first in "_func" system space. This
>>> is a problem if node is in read-only mode (replica).
>>>
>>> Still people would like to have a way to run such functions
>>> even in ro mode. For this sake we implement "cfunc" lua
>>> module.
>>>
>>> Fixes #4692
>>>
>>> Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
>>>
>>> @TarantoolBot document
>>> Title: cfunc module
>>
>> 1. The documentation will go to a github issue, where it looks super
>> broken as I checked. Please, try to use github markdown here.
> 
> You know, I've been using sphinx syntax for a purpose -- this commit
> message can be simply extracted and being put into our doc.repo. Otherwise
> it becomes a double work: first we write commit message in own format
> then out docs team need to reformat it to sphinx. Taking into account
> that we simply don't have enough men power we could optimize this procedure.
> Note -- I don't mind to rewrite it in MD format but probably sphinx is better?

I just stated a fact - whatever you post after "TarantoolBot document" goes to
a github issue as is, unedited. Therefore it will be interpreted as github
markdown, unconditionally. So you need to write things to make them readable
in github. If you use sphinx markdown, it won't be displayed as sphinx markdown
anyway. It will be displayed in github markdown.

Talking of the idea about writing docs for copy-pasting, I don't think it can be
done with the current flow of documentation updates. Doc team anyway needs to
find a place to put your text into, translate it to Russian, review and correct
your markdown. Also if we need to write in sphinx style, it means we need to
patch docbot to somehow turn github markdown off, and make other team members
learn this markdown - how to write it and validate. With all that said - why
do we even need a whole documentation team, if this is basically all they do?

I would better let us write more free-style documentation requests, and let the
doc team do their job.

>>> +
>>> +	cfunc = malloc(sizeof(*cfunc) + name_len + 1);
>>> +	if (cfunc == NULL) {
>>> +		diag_set(OutOfMemory, sizeof(*cfunc), "malloc", "cfunc");
>>
>> 12. You allocated 'sizeof(*cfunc) + name_len + 1)', not only sizeof.
> 
> I know, the name of the function is placed right after the structure.
> It is intended.

How is it related? diag_set in the second argument takes allocation
size. You tried to allocate sizeof(*cfunc) + name_len + 1, but
reported sizeof(*cfunc), which is smaller. It does not depend on what
you allocate. Only how much.

>> In that way the idea to rename cfunc to cbox or something like that looks
>> even better. We could provide methods to operate on entire modules. So it
>> would be
>>
>> 	f = cbox.load_func() -- Create a function.
>> 	f:unload()           -- Unload a function.
>> 	cbox.reload_module() -- Reload module and all functions in it.
>> 	cbox.unload_module() -- Unload the module from the memory.
> 
> maybe
> 
> 	f = cmod.create(name)		-- just like in schema.func
> 	f:drop()			-- same
> 	cmod.module('reload', name)
> 	cmod.module('unload', name)
> 
> ? I don't mind to use cbox name either but cmod somehow close to
> what we're doing.

The method name as string 'reload' and 'unload' looks super ugly,
and wouldn't work with autocompletion. I would better go for explicit
methods module_reload and module_unload. Or like you proposed later -
module.reload and module.unload. (Personally I would prefer the first
way, because it would mean less Lua tables, and simpler autocompletion.)

>>> +	}
>>> +
>>> +	size_t name_len;
>>> +	const char *name = lua_tolstring(L, 1, &name_len);
>>> +
>>> +	struct cfunc *cfunc = cfunc_lookup(name, name_len);
>>> +	if (cfunc == NULL) {
>>> +		const char *fmt = tnt_errcode_desc(ER_NO_SUCH_FUNCTION);
>>> +		diag_set(IllegalParams, fmt, name);
>>> +		return luaT_error(L);
>>> +	}
>>> +
>>> +	lua_State *args_L = luaT_newthread(tarantool_L);
>>
>> 18. Wtf? Why can't you use L? Why do you even move anything here
>> between the stacks?
> 
> Well, actually it comes from lbox_func_call, I couldn't extract this
> into a separate helper. To be honest I do not really undertand why
> luaT_newthread is used in lbox_func_call but I presume this is the
> template of calling external functions in Lua?

We don't copy code presuming that it does something. Lets better
understand why is it needed instead of blindly copying it.
Currently I don't see any reason why is it needed.

Tbh I don't know why is it needed in lbox_func_call() either. The
comment there is super unclear about that. It just says what is
done, and not why.

  reply	other threads:[~2020-10-05 21:59 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-01 13:51 [Tarantool-patches] [PATCH v4 0/6] " Cyrill Gorcunov
2020-10-01 13:51 ` [Tarantool-patches] [PATCH v4 1/6] box/func: factor out c function entry structure Cyrill Gorcunov
2020-10-01 13:51 ` [Tarantool-patches] [PATCH v4 2/6] box/func: provide module_sym_call Cyrill Gorcunov
2020-10-01 13:51 ` [Tarantool-patches] [PATCH v4 3/6] box/func: more detailed error in module reloading Cyrill Gorcunov
2020-10-01 13:51 ` [Tarantool-patches] [PATCH v4 4/6] box/func: export func_split_name helper Cyrill Gorcunov
2020-10-01 13:51 ` [Tarantool-patches] [PATCH v4 5/6] box/func: implement cfunc Lua module Cyrill Gorcunov
2020-10-03 13:55   ` Vladislav Shpilevoy
2020-10-05 10:31     ` Cyrill Gorcunov
2020-10-05 21:59       ` Vladislav Shpilevoy [this message]
2020-10-06 12:55         ` Cyrill Gorcunov
2020-10-01 13:51 ` [Tarantool-patches] [PATCH v4 6/6] test: box/cfunc -- add simple module test Cyrill Gorcunov
2020-10-03 13:55   ` Vladislav Shpilevoy
2020-10-03 13:55 ` [Tarantool-patches] [PATCH v4 0/6] box/func: implement cfunc Lua module Vladislav Shpilevoy
2020-10-05 11:51   ` Cyrill Gorcunov
2020-10-05 21:59     ` Vladislav Shpilevoy

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=d977ed4e-5481-342c-fb19-d64848a956be@tarantool.org \
    --to=v.shpilevoy@tarantool.org \
    --cc=alexander.turenko@tarantool.org \
    --cc=gorcunov@gmail.com \
    --cc=tarantool-patches@dev.tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH v4 5/6] box/func: implement cfunc Lua module' \
    /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