From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <alexander.turenko@tarantool.org>
Received: from smtp56.i.mail.ru (smtp56.i.mail.ru [217.69.128.36])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by dev.tarantool.org (Postfix) with ESMTPS id 97662469719
 for <tarantool-patches@dev.tarantool.org>;
 Fri, 21 Feb 2020 00:00:06 +0300 (MSK)
Date: Fri, 21 Feb 2020 00:00:26 +0300
From: Alexander Turenko <alexander.turenko@tarantool.org>
Message-ID: <20200220210026.tdicjidbhky3guvu@tkn_work_nb>
References: <20200214132220.29830-1-gorcunov@gmail.com>
 <20200214132220.29830-3-gorcunov@gmail.com>
 <20200214141704.GA10968@atlas> <20200214142220.GY21061@uranus>
 <20200214142919.GB10968@atlas> <20200214143135.GZ21061@uranus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20200214143135.GZ21061@uranus>
Subject: Re: [Tarantool-patches] [PATCH v8 2/2] fiber: leak slab if unable
 to bring prots back
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: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: tml <tarantool-patches@dev.tarantool.org>, Vladislav Shpilevoy <v.shpilevoy@tarantool.org>

Guys, please don't remove me from CC in discussions, where I
participated.

On Fri, Feb 14, 2020 at 05:31:35PM +0300, Cyrill Gorcunov wrote:
> On Fri, Feb 14, 2020 at 05:29:19PM +0300, Konstantin Osipov wrote:
> > > 
> > > As far as I understand we gonna drop guard pages for release
> > > builds only, for debug builds it will be with us, no?
> > 
> > Panic in debug is ok.
> 
> Thanks for clarification, Kostya! I'll rework the series once time permit.

We using guard page for a long time (f3155daa 'Add a guard page to the
end fiber stack', 2015) and reconsidering the approach as well as
reimplementation may took significant time, may be stuck due to some
reason or be rejected (for debug builds or at all). It also requires
laborious performance testing. I propose to don't block this bugfix.

For panic on debug: it is okay, but not good, when we able to operate
further. In some rare cases it may even affect customers, when we're
working with them to catch a problem on a debug build and it spins on
some part of production servers under load for a while.

When we detect that we made something wrong, assertion fail looks good.
When we detect that a system resource is exhausted and we able to
proceed with this situation w/o data corruption, it is better to do the
same thing in both release and debug builds.

WBR, Alexander Turenko.