From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gorcunov@gmail.com>
Received: from mail-lf1-f67.google.com (mail-lf1-f67.google.com
 [209.85.167.67])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by dev.tarantool.org (Postfix) with ESMTPS id E3FAC469719
 for <tarantool-patches@dev.tarantool.org>;
 Fri, 30 Oct 2020 12:52:00 +0300 (MSK)
Received: by mail-lf1-f67.google.com with SMTP id a7so7053367lfk.9
 for <tarantool-patches@dev.tarantool.org>;
 Fri, 30 Oct 2020 02:52:00 -0700 (PDT)
Date: Fri, 30 Oct 2020 12:51:57 +0300
From: Cyrill Gorcunov <gorcunov@gmail.com>
Message-ID: <20201030095157.GD198833@grain>
References: <20201014133535.224573-1-gorcunov@gmail.com>
 <20201014133535.224573-2-gorcunov@gmail.com>
 <8706dd6e-0b8d-f3f1-2344-f1b24906eecd@tarantool.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8706dd6e-0b8d-f3f1-2344-f1b24906eecd@tarantool.org>
Subject: Re: [Tarantool-patches] [PATCH v8 1/4] box/func: factor out c
	function entry structure
List-Id: Tarantool development patches <tarantool-patches.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/>
List-Post: <mailto:tarantool-patches@dev.tarantool.org>
List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe>
To: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Cc: tml <tarantool-patches@dev.tarantool.org>

On Thu, Oct 29, 2020 at 11:15:51PM +0100, Vladislav Shpilevoy wrote:
...
> > +int
> > +module_sym_load(struct module_sym *mod_sym)
> > +{
> > +	assert(mod_sym->addr == NULL);
> > +
> > +	struct func_name name;
> > +	func_split_name(mod_sym->name, &name);
> > +
> > +	struct module *module = module_cache_find(name.package,
> > +						  name.package_end);
> > +	if (module == NULL) {
> > +		/* Try to find loaded module in the cache */
> > +		module = module_load(name.package, name.package_end);
> > +		if (module == NULL)
> > +			return -1;
> > +		if (module_cache_put(module)) {
> 
> 1. Please, use explicit != 0.
> https://github.com/tarantool/tarantool/wiki/Code-review-procedure#code-style

OK

> 
> > +			module_delete(module);
> > +			return -1;
> > +		}
> > +	}
> > +
> > +	mod_sym->addr = module_sym(module, name.sym);
> > +	if (mod_sym->addr == NULL)
> > +		return -1;
> 
> 2. If the module was loaded first time here, it is not unloaded in case of
> an error in this place.

Just like it was before the patch. The patch simply factor outs the old
code. It doesn't improve it (because, lets be honest this is a min problem
for module management -- we've to check for module symbol not at moment
of calling it but rather at the moment when we load a function). That
said the issue with module management is known and I think we need to
rework modules code more deeply, but not in this series. In the
series it remains exactly as it was.

> >  
> > +/**
> > + * Callable symbol bound to a module.
> > + */
> > +struct module_sym {
> > +	/**
> > +	 * Anchor for module membership.
> > +	 */
> > +	struct rlist item;
> > +	/**
> > +	 * For C functions, address of the function.
> > +	 */
> > +	box_function_f addr;
> > +	/**
> > +	 * Each stored function keeps a handle to the
> > +	 * dynamic library for the C callback.
> > +	 */
> 
> 3. Can't parse the comment. What is the 'C callback'?
> And why is this function stored? After you extracted it
> from struct func_c, it is not related to _func space, and
> is not stored.

It is stored in memory. The C callback is the function we
call, so we keep a pointer to a module. If shuch comment
confuses lets change it to something like "Each function
keeps a handle to the module where the symbol relies"?