From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) (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 3CF4D46971A for ; Thu, 12 Dec 2019 11:51:02 +0300 (MSK) Received: by mail-lj1-f179.google.com with SMTP id r19so1347811ljg.3 for ; Thu, 12 Dec 2019 00:51:02 -0800 (PST) Date: Thu, 12 Dec 2019 11:50:59 +0300 From: Konstantin Osipov Message-ID: <20191212085059.GC24448@atlas> References: <20191211235703.GK1214@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191211235703.GK1214@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH 1/2] fiber: unref fiber.storage via global Lua state List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Munkin Cc: tarantool-patches@dev.tarantool.org, Vladislav Shpilevoy * Igor Munkin [19/12/12 03:03]: > I spent some time knee deep into fibers machinery and totally agree with > this fix: the most safe approach is "unrefing" storage entity via > tarantool_L coro, taking into account the possible unref of the fiber's > one and its consequtive collection. > > However, I don't get why we need to apply these changes, considering > your follow-up patch. Could you please provide a bit more detailed > rationale? I think it's worth applying them simply because the follow up changes may end up being something completely different. I agree this is a good fix. -- Konstantin Osipov, Moscow, Russia