From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com [209.85.208.196]) (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 2DE3646971A for ; Thu, 12 Dec 2019 11:46:08 +0300 (MSK) Received: by mail-lj1-f196.google.com with SMTP id r19so1331967ljg.3 for ; Thu, 12 Dec 2019 00:46:08 -0800 (PST) Date: Thu, 12 Dec 2019 11:46:03 +0300 From: Konstantin Osipov Message-ID: <20191212084603.GA24448@atlas> References: <20191210083258.GD21413@atlas> <2c8fe897-9a9d-849d-463e-5fadff982b8c@tarantool.org> <20191211070830.GA5953@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Tarantool-patches] [PATCH 2/2] fiber: destroy fiber.storage created by iproto List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladislav Shpilevoy Cc: tarantool-patches@dev.tarantool.org * Vladislav Shpilevoy [19/12/12 00:27]: > - I moved cleanup to iproto.cc, and called it tx_fiber_cleanup(). > By analogue with tx_fiber_init() which currently initializes the > fiber; > > - I made cleanup triggers always clean them by themselves to remove > trigger_destroy() from fiber.c. > > But it didn't help me to understand, why are you saying, that > tx and session should not use these triggers. Tx, in case it was > not removed from fiber before its cleanup, should be destroyed. > Session uses that trigger to destroy local one-fiber sessions, > which die together with the fiber getting recycled/killed. So > what is a problem? That trigger perfectly fits all the needs. OK, the function itself may be a match, but it doesn't make the idea of using the same trigger object for everything right, don't you think? My point is that you do not only move where the function is invoked, but also where the trigger list object is stored. Can you move it to Lua fiber object and iproto_msg object? There could be no other entry points to the request, so my point is that the trigger is part of request state, not fiber state. Does it make any sense? -- Konstantin Osipov, Moscow, Russia