From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gorcunov@gmail.com>
Return-Path: <gorcunov@gmail.com>
Date: Tue, 5 Mar 2019 11:27:11 +0300
From: Cyrill Gorcunov <gorcunov@gmail.com>
Subject: Re: [tarantool-patches] [rfc 3/4] core/fiber: Put static watermark
 into stack to track its usage
Message-ID: <20190305082711.GL13301@uranus.lan>
References: <20190302125524.279852704@gmail.com>
 <20190302130034.050488016@gmail.com>
 <20190305082029.GL21955@chai>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190305082029.GL21955@chai>
To: Konstantin Osipov <kostja@tarantool.org>
Cc: tarantool-patches@freelists.org, vdavydov.dev@gmail.com
List-ID: <tarantool-patches.dev.tarantool.org>

On Tue, Mar 05, 2019 at 11:20:29AM +0300, Konstantin Osipov wrote:
> 
> As a policy we write meaningful comments for every function, static or not,
> obvious or not. The idea of such a comment is to reflect the
> author's intent and technical trade-offs considered when designing
> a function. The comment should preferably be concise, however.
> 
> > +/*
> > + * Random values generated with uuid.
> > + * Try to fit a cache line.
> 
> I don't understand this comment. Since you're putting a poison-gap
> between each number, how could you possibly fit a cache line?

size of the poison_pool itself, we actively access this
array, so better keep it small enough

> > + */
> > +static const uint64_t poison_pool[] = {
> > +	0x74f31d37285c4c37, 0xb10269a05bf10c29,
> > +	0x0994d845bd284e0f, 0x9ffd4f7129c184df,
> > +	0x357151e6711c4415, 0x8c5e5f41aafe6f28,
> > +	0x6917dd79e78049d5, 0xba61957c65ca2465,
> > +};
> > +
> > +/*
> > + * We poison by 8 bytes as it natural for stack
> > + * step on x86-64. Also 128 byte gap between
> > + * poison values should cover a common cases.
> 
> > +	/** Stack watermark addr for overflow detection. */
> > +	void *stack_wmark_ofl;
> 
> Generally we try to avoid abbreviations unless really necessary.
> Why not simply stack_overflow_watermark? 

Well, as to me it is too long, but sure, will update.

	Cyrill