Tarantool development patches archive
 help / color / mirror / Atom feed
From: Cyrill Gorcunov via Tarantool-patches <tarantool-patches@dev.tarantool.org>
To: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Cc: tml <tarantool-patches@dev.tarantool.org>
Subject: Re: [Tarantool-patches] [PATCH v20 4/7] box/module_cache: introduce modules subsystem
Date: Wed, 7 Apr 2021 10:03:52 +0300	[thread overview]
Message-ID: <YG1ZWLagD4J6gshK@grain> (raw)
In-Reply-To: <5bd028c8-21fe-8395-816b-1d5464aaa1ca@tarantool.org>

On Wed, Apr 07, 2021 at 01:43:26AM +0200, Vladislav Shpilevoy wrote:
> 
> The module cache job is to cache, not to own. Owners are the schema
> modules and box.lib modules. The cache **does not own**, therefore it
> can't just delete whatever it wants.
> 
> > And the bug is rather in caller side
> > which should had install some hooks to detect exits and unref objects.
> > 
> > But as you pointed below Lua is not properly terminated and the
> > subsystem does only thing it knows about -- unref objects it has
> > allocated (we setup a first ref upon allocation). It is still somehow
> > ugly because of potential extra refs on Lua side and I now think
> > maybe we should free allocated memory in a force way.
> 
> As I said, under no circumstances you can free the objects which you do
> not own.

With this assumption OS should not release userspace memory on process
termination if userspace application didn't call free(), right? OS allocated
memory, cached it in pages but doesn't own it, userspace should call free
first? Vlad, the key difference here is that our engine does not shutdown
and then tarantool continue to work without the cache. It is exit path where
we should release all memory. This as well applies to all other caches,
slabs and etc. It doesn't matter that currently we simply have no way
to jump into Lua internals and force clear all references sits there.

I hardly convince you here but I see your point and partly agree.

> > But that's
> > true that even though we won't have a clean exit. I tend to agree
> > that simply free and zap the hash table is best what we could do
> > for now. Will update.
> 
> I am fine with freeing the hash table itself and setting it to NULL, if
> you want to free something so hard. Then at least in future it would
> crash right away on any attempt to load/unload something after the cache
> was destroyed. Not at some random time due to memory corruptions if you
> would free the modules which you don't own and then they would be
> accessed. Might happen easily if we ever would allow to load the modules
> from C API, or would terminate Lua properly.

Sure. I think this is the best option, will do.

  reply	other threads:[~2021-04-07  7:03 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-02 12:34 [Tarantool-patches] [PATCH v20 0/7] box: implement box.lib Lua module Cyrill Gorcunov via Tarantool-patches
2021-04-02 12:34 ` [Tarantool-patches] [PATCH v20 1/7] box/schema: make sure hashes are created Cyrill Gorcunov via Tarantool-patches
2021-04-05  9:28   ` Serge Petrenko via Tarantool-patches
2021-04-05  9:50     ` Cyrill Gorcunov via Tarantool-patches
2021-04-05 10:13       ` Serge Petrenko via Tarantool-patches
2021-04-05 15:45   ` Vladislav Shpilevoy via Tarantool-patches
2021-04-06  7:44     ` Cyrill Gorcunov via Tarantool-patches
2021-04-02 12:34 ` [Tarantool-patches] [PATCH v20 2/7] box/func: module_reload -- drop redundant argument Cyrill Gorcunov via Tarantool-patches
2021-04-05 10:23   ` Serge Petrenko via Tarantool-patches
2021-04-05 10:26     ` Serge Petrenko via Tarantool-patches
2021-04-05 10:31       ` Cyrill Gorcunov via Tarantool-patches
2021-04-02 12:34 ` [Tarantool-patches] [PATCH v20 3/7] box/func: fix modules functions restore Cyrill Gorcunov via Tarantool-patches
2021-04-05 10:53   ` Serge Petrenko via Tarantool-patches
2021-04-05 11:26     ` Cyrill Gorcunov via Tarantool-patches
2021-04-05 11:42       ` Serge Petrenko via Tarantool-patches
2021-04-05 15:47   ` Vladislav Shpilevoy via Tarantool-patches
2021-04-06  8:38     ` Cyrill Gorcunov via Tarantool-patches
2021-04-06 20:02       ` Vladislav Shpilevoy via Tarantool-patches
2021-04-06 20:42         ` Cyrill Gorcunov via Tarantool-patches
2021-04-02 12:34 ` [Tarantool-patches] [PATCH v20 4/7] box/module_cache: introduce modules subsystem Cyrill Gorcunov via Tarantool-patches
2021-04-05 12:34   ` Serge Petrenko via Tarantool-patches
2021-04-05 15:52   ` Vladislav Shpilevoy via Tarantool-patches
2021-04-06 14:33     ` Cyrill Gorcunov via Tarantool-patches
2021-04-06 20:09       ` Vladislav Shpilevoy via Tarantool-patches
2021-04-06 22:05         ` Cyrill Gorcunov via Tarantool-patches
2021-04-06 23:43           ` Vladislav Shpilevoy via Tarantool-patches
2021-04-07  7:03             ` Cyrill Gorcunov via Tarantool-patches [this message]
2021-04-02 12:34 ` [Tarantool-patches] [PATCH v20 5/7] box/schema.func: switch to new module api Cyrill Gorcunov via Tarantool-patches
2021-04-05 15:56   ` Vladislav Shpilevoy via Tarantool-patches
2021-04-02 12:34 ` [Tarantool-patches] [PATCH v20 6/7] box: implement box.lib module Cyrill Gorcunov via Tarantool-patches
2021-04-05 16:04   ` Vladislav Shpilevoy via Tarantool-patches
2021-04-07 16:59     ` Cyrill Gorcunov via Tarantool-patches
2021-04-07 20:22       ` Cyrill Gorcunov via Tarantool-patches
2021-04-07 20:28         ` Vladislav Shpilevoy via Tarantool-patches
2021-04-07 20:37           ` Cyrill Gorcunov via Tarantool-patches
2021-04-07 20:45             ` Cyrill Gorcunov via Tarantool-patches
2021-04-07 21:04               ` Vladislav Shpilevoy via Tarantool-patches
2021-04-02 12:34 ` [Tarantool-patches] [PATCH v20 7/7] test: add box.lib test Cyrill Gorcunov via Tarantool-patches
2021-04-05 16:04   ` Vladislav Shpilevoy via Tarantool-patches
2021-04-05 15:45 ` [Tarantool-patches] [PATCH v20 0/7] box: implement box.lib Lua module Vladislav Shpilevoy via Tarantool-patches

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=YG1ZWLagD4J6gshK@grain \
    --to=tarantool-patches@dev.tarantool.org \
    --cc=gorcunov@gmail.com \
    --cc=v.shpilevoy@tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH v20 4/7] box/module_cache: introduce modules 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