From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Return-Path: Date: Tue, 2 Apr 2019 11:09:28 +0300 From: Cyrill Gorcunov Subject: Re: [PATCH 2/2] lib/core/fiber: Allow to extend default stack size Message-ID: <20190402080928.GH2431@uranus.lan> References: <20190327093506.zsxzchje2un76rcp@esperanza> <20190327094618.GH20626@uranus.lan> <20190327101552.d3b6xvezm3rigszm@esperanza> <20190327102333.GJ20626@uranus.lan> <20190401174114.GD2431@uranus.lan> <20190401185845.GA21609@chai> <20190401191909.GE2431@uranus.lan> <20190401205109.GA23775@chai> <20190401220516.GF2431@uranus.lan> <20190402071411.GA25072@chai> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190402071411.GA25072@chai> To: Konstantin Osipov Cc: tml , Vladimir Davydov List-ID: On Tue, Apr 02, 2019 at 10:14:11AM +0300, Konstantin Osipov wrote: > * Cyrill Gorcunov [19/04/02 01:09]: > > > I don't think we should bother with making sure the stack is right > > > for all fibers. You set the stack size, then you start fibers > > > which depend on it. > > > > Kostja, "require('fiber').cfg{stack_size=value})" implies that > > lua read and parse it, but lua *itself* runs inside a fiber where > > we've the stack size already allocated and what is worse its size > > is compiled in. Next time when "readline" developers increase *own* > > stack size we hit the same bug. Users simply won't have a chance to > > run tarantool, instead they will have to wait us to increase default > > stack size and rebuild the program. > > Yes. We could remedy this by making the first (REPL or script) > fiber stack sufficiently large at once. It is true that we can make stack size for the "interactive" fiber big enough but you know it looks somehow fishy for me -- we simply hope that size gonne be enough not giving a way to customize these early sizes. I won't insist though. Need to figure out how to work with our cfg engine.