Date: Mon, 22 Sep 2014 15:18:54 -0400 From: John Baldwin <jhb@freebsd.org> To: "Justin T. Gibbs" <gibbs@scsiguy.com> Cc: Konstantin Belousov <kostikbel@gmail.com>, "Ivan A. Kosarev" <ivan@ivan-labs.com>, freebsd-current@freebsd.org, doc@freebsd.org Subject: Re: libthr and main thread stack size Message-ID: <1502207.DmYsYJhHW2@ralph.baldwin.cx> In-Reply-To: <F0A2DBD9-195E-4F4E-BA36-1F7644827111@scsiguy.com> References: <53E36E84.4060806@ivan-labs.com> <20140920170658.GE2210@kib.kiev.ua> <F0A2DBD9-195E-4F4E-BA36-1F7644827111@scsiguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday, September 21, 2014 09:36:25 PM Justin T. Gibbs wrote: > On Sep 20, 2014, at 11:06 AM, Konstantin Belousov <kostikbel@gmail.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1502207.DmYsYJhHW2>