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 80312469719 for ; Sat, 15 Feb 2020 20:55:50 +0300 (MSK) Received: by mail-lj1-f196.google.com with SMTP id d10so14239256ljl.9 for ; Sat, 15 Feb 2020 09:55:50 -0800 (PST) Date: Sat, 15 Feb 2020 20:55:47 +0300 From: Cyrill Gorcunov Message-ID: <20200215175547.GB2527@uranus> References: <20200213205618.7982-1-gorcunov@gmail.com> <20200213205618.7982-2-gorcunov@gmail.com> <46c82f5e-5e4c-ec4a-b8ce-b999e6a6230c@tarantool.org> <20200214075416.GS21061@uranus> <510f66ef-182f-36dd-2e18-64562bf38a86@tarantool.org> <20200215065757.GA2527@uranus> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Tarantool-patches] [PATCH v7 1/2] fiber: set diagnostics at madvise/mprotect failure List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladislav Shpilevoy Cc: tml On Sat, Feb 15, 2020 at 04:41:39PM +0100, Vladislav Shpilevoy wrote: > > > > It highly depends on compiler. It might be optimized and not allocated > > on the stack at all or it might be allocated and loaded in the procedure > > prologue (which will happen with optimization disabled). > > This is what I don't like - dependency on whether a compiler will > optimize something or not. I mean the different thing. If variable declared as const inside prologue it might be or might be not rolled in without load. To prevent possible load I use static var. > > > > And I'll have to modify both -- comment and code if we need > > to change the permissions. Thanks but no. We could do better > > and keep R|W in one place. > > I can't imagine why would we need other flags here, but anyway if > that will happen, I am sure it will change much more than just a > comment. However, this is subjective. Yup. > > > But if you bothers this approach I could just inline R|W, no problem. > > Usually for similar things, when it is wanted to have a constant > expression as a single identifier, enum works well, and we use > that a lot, for the same reasons. So I propose you to consider a > enum then. Anonymous enum in fiber.c. Sure, thanks > > Still there is a really big question remains -- what to do with > > the issue. I suspect Kostya has something different in mind. So > > for now I'm giving up cooking this series (until I'll be sure > > that I really understand the next step to walk). > > Ok. Btw, I don't understand what is wrong with the current > solution. I though of extending code on the top of this series to drop r|w in release builds completely, but not right now. So lets wait for Kostya to respond.