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>
Subject: Re: [Tarantool-patches] [PATCH v8 2/4] module_cache: move module handling into own subsystem
Date: Sat, 31 Oct 2020 01:15:38 +0100	[thread overview]
Message-ID: <e9385e38-e372-b60a-9e77-10ed8b813f47@tarantool.org> (raw)
In-Reply-To: <20201030101519.GE198833@grain>

>>> +
>>> +/**
>>> + * Find a path to a module using Lua's package.cpath.
>>> + *
>>> + * @param ctx module find context
>>> + * @param[out] ctx->path path to shared library.
>>> + * @param[out] ctx->path_len size of @a ctx->path buffer.
>>
>> 2. The last two lines are not params. The only parameter is ctx. If
>> you want to describe it, it should be done under the same @param.
>> Otherwise the comment looks mismatching the signature. I gonna say
>> that again. I don't force to use Doxygen, but if you decide to use it,
>> it should be done correctly.
> 
> Well, I didnt find any reference for the correct way to describe such
> updates of internal structures.

Doxygen syntax can be found on the official site, available on a first
link from google when you type 'doxygen'. If it does not provide a special
syntax for describing changes of individual fields of a single parameter,
then you need to describe them in the comment main part, or the @param
describing the parameter, like I proposed above.

> I think I better drop this doxy-style
> comment.

Or drop it, yes.

>>> + *
>>> + * @return 0 on succes, -1 otherwise, diag is set.
>>> + */
>>> +static int
>>> +module_find(struct module_find_ctx *ctx)
>>> diff --git a/src/box/module_cache.h b/src/box/module_cache.h
>>> new file mode 100644
>>> index 000000000..3f275024a
>>> --- /dev/null
>>> +++ b/src/box/module_cache.h
>>> @@ -0,0 +1,156 @@
>>> +/*
>>> + * SPDX-License-Identifier: BSD-2-Clause
>>> + *
>>> + * Copyright 2010-2020, Tarantool AUTHORS, please see AUTHORS file.
>>> + */
>>> +
>>> +#pragma once
>>> +
>>> +#include <small/rlist.h>
>>> +
>>> +#include "func_def.h"
>>
>> 3. Func_def heavily depends on schema. Also it is a part of
>> all the _func handling, meaning this is a cyclic dependency now -
>> module_cache depends on func and vice versa.
> 
> Nope. Where you get it? func_def.h is not touched in this series
> at all. What we have now

I didn't say you touched it. I said it depends on schema, and is a part of
stored functions code. Including func.h, func.c, call.h, call.c, and the
others.

> module_cache.h: func_def.h
> func.h: module_cache.h func_def.h
> func_def.h: trivia/util.h field_def.h opt_def.h
> 
> I don't understand which cyclic dependency you mean.

func.h/func.c/func_def.h/func_def.c are a part of the subsystem for
calling stored functions. Inside of the schema. It also depends on
module_cache.

module_cache is not related to schema, but depends on func_def.h
somewhy. This is the cycle. Module_cache and stored functions depend
on each other.

Talking of the schema details: func_def.h operates on user ID, on
function ID, on Lua specifics like sandboxing, knows about multikey,
and so on. It heavily depends on schema, and module_cache should not
depend on schema.

AFAIS, you included it simply because it defined box_function_ctx and
box_function_f. But it should be vice-versa.

I did this and all was built fine:

====================
diff --git a/src/box/func_def.h b/src/box/func_def.h
index d99d89190..75cd6a0d3 100644
--- a/src/box/func_def.h
+++ b/src/box/func_def.h
@@ -168,20 +168,6 @@ func_def_dup(struct func_def *def);
 int
 func_def_check(struct func_def *def);
 
-/**
- * API of C stored function.
- */
-
-struct port;
-
-struct box_function_ctx {
-	struct port *port;
-};
-
-typedef struct box_function_ctx box_function_ctx_t;
-typedef int (*box_function_f)(box_function_ctx_t *ctx,
-	     const char *args, const char *args_end);
-
 #ifdef __cplusplus
 }
 #endif
diff --git a/src/box/module_cache.h b/src/box/module_cache.h
index 3f275024a..1ec7f0042 100644
--- a/src/box/module_cache.h
+++ b/src/box/module_cache.h
@@ -8,12 +8,20 @@
 
 #include <small/rlist.h>
 
-#include "func_def.h"
-
 #if defined(__cplusplus)
 extern "C" {
 #endif /* defined(__cplusplus) */
 
+struct port;
+
+struct box_function_ctx {
+	struct port *port;
+};
+
+typedef struct box_function_ctx box_function_ctx_t;
+typedef int (*box_function_f)(box_function_ctx_t *ctx,
+	     const char *args, const char *args_end);
+
 /**
  * Function name descriptor: a symbol and a package.
  */

  reply	other threads:[~2020-10-31  0:15 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-14 13:35 [Tarantool-patches] [PATCH v8 0/4] box/cbox: implement cfunc Lua module Cyrill Gorcunov
2020-10-14 13:35 ` [Tarantool-patches] [PATCH v8 1/4] box/func: factor out c function entry structure Cyrill Gorcunov
2020-10-29 22:15   ` Vladislav Shpilevoy
2020-10-30  9:51     ` Cyrill Gorcunov
2020-10-31  0:13       ` Vladislav Shpilevoy
2020-10-31 15:27         ` Cyrill Gorcunov
2020-10-14 13:35 ` [Tarantool-patches] [PATCH v8 2/4] module_cache: move module handling into own subsystem Cyrill Gorcunov
2020-10-29 22:15   ` Vladislav Shpilevoy
2020-10-30 10:15     ` Cyrill Gorcunov
2020-10-31  0:15       ` Vladislav Shpilevoy [this message]
2020-10-31 15:29         ` Cyrill Gorcunov
2020-10-14 13:35 ` [Tarantool-patches] [PATCH v8 3/4] box/cbox: implement cbox Lua module Cyrill Gorcunov
2020-10-29 22:15   ` Vladislav Shpilevoy
2020-10-30 12:51     ` Cyrill Gorcunov
2020-10-31  0:21       ` Vladislav Shpilevoy
2020-10-31 21:59         ` Cyrill Gorcunov
2020-11-01  8:26           ` Cyrill Gorcunov
2020-11-02 22:25           ` Vladislav Shpilevoy
2020-11-03  7:26             ` Cyrill Gorcunov
2020-11-12 22:54     ` Vladislav Shpilevoy
2020-11-13 18:30       ` Cyrill Gorcunov
2020-10-14 13:35 ` [Tarantool-patches] [PATCH v8 4/4] test: box/cfunc -- add simple module test Cyrill Gorcunov

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=e9385e38-e372-b60a-9e77-10ed8b813f47@tarantool.org \
    --to=v.shpilevoy@tarantool.org \
    --cc=gorcunov@gmail.com \
    --cc=tarantool-patches@dev.tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH v8 2/4] module_cache: move module handling into own subsystem' \
    /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