From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 22 May 2018 17:39:29 +0300 From: Vladimir Davydov Subject: Re: [PATCH 3/8] memtx: pass engine to memory allocation functions Message-ID: <20180522143929.jhu77fa6n57gltoo@esperanza> References: <9723814bc47225881dabb75f4ebb72aab59f1724.1526987033.git.vdavydov.dev@gmail.com> <20180522134728.GC11201@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180522134728.GC11201@atlas> To: Konstantin Osipov Cc: tarantool-patches@freelists.org List-ID: On Tue, May 22, 2018 at 04:47:28PM +0300, Konstantin Osipov wrote: > * Vladimir Davydov [18/05/22 15:10]: > > We need this so that we can force garbage collection when we are short > > on memory. There are two such functions: one is used for allocating > > index extents, another for allocating tuples. Index allocating function > > has an opaque context so we simply reuse it for passing memtx engine to > > it. To pass memtx engine to tuple allocating function, we add an opaque > > engine specific pointer to tuple_format (engine_data) and set it to > > memtx_engine for memtx spaces. > > Please rename engine_data to engine. OK. > I would not use an opaque pointer either, reference the engine > explicitly. The reason I decided to make it an opaque pointer is that we might want to reuse it in vinyl to make vy_max_tuple_size, which is currently a global variable, a part of vy_env. The problem is vy_max_tuple_size is used in vy_stmt.c, which knows nothing about vy_env, so to avoid cross dependencies we will probably have to introduce vy_stmt_env to store this variable and make tuple_format reference not the whole vy_env, but only vy_stmt_env hence the opaque pointer.