From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 19:22:05 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07CC8D1C; Mon, 22 Sep 2014 19:22:05 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D2463A9F; Mon, 22 Sep 2014 19:22:04 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7E212B99A; Mon, 22 Sep 2014 15:22:03 -0400 (EDT) From: John Baldwin To: "Justin T. Gibbs" Subject: Re: libthr and main thread stack size Date: Mon, 22 Sep 2014 15:18:54 -0400 Message-ID: <1502207.DmYsYJhHW2@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: References: <53E36E84.4060806@ivan-labs.com> <20140920170658.GE2210@kib.kiev.ua> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 22 Sep 2014 15:22:03 -0400 (EDT) Cc: Konstantin Belousov , "Ivan A. Kosarev" , freebsd-current@freebsd.org, doc@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 19:22:05 -0000 On Sunday, September 21, 2014 09:36:25 PM Justin T. Gibbs wrote: > On Sep 20, 2014, at 11:06 AM, Konstantin Belousov wrote: > > On Fri, Sep 19, 2014 at 03:27:25PM -0400, John Baldwin wrote: > >> I suspect it was done out of reasons of being overly conservative in > >> interpreting RLIMIT_STACK. I think it is quite surprising behavior > >> though and would rather we make your option the default and implement > >> what the Open Group says above. > > > > Ok, below is the patch. I felt bad about adding yet another magic and > > undocumented tunable to our libthr. Since there seems to be no > > alternative than a tunable to enforce old behaviour, I documented > > the quirks I am aware of. > > Why do we need to support the old behavior? Any program that ran in the old > model will run in the new. In the unlikely event that someone was using > the old scheme for administrative control, there are other mechanisms for > this already available that we can point them to instead. I agree with this. In my experience the issue it has always been the opposite (people having issues with the main stack shrinking). -- John Baldwin