From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23566 invoked by alias); 17 Jan 2002 03:55:32 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 23388 invoked from network); 17 Jan 2002 03:55:29 -0000 Received: from unknown (HELO web14504.mail.yahoo.com) (216.136.224.67) by sources.redhat.com with SMTP; 17 Jan 2002 03:55:29 -0000 Message-ID: <20020117035529.2169.qmail@web14504.mail.yahoo.com> Received: from [203.97.2.243] by web14504.mail.yahoo.com via HTTP; Thu, 17 Jan 2002 14:55:29 EST Date: Wed, 16 Jan 2002 20:32:00 -0000 From: =?iso-8859-1?q?Danny=20Smith?= Subject: Re: binutils, why default stack size this low ? To: Pascal Obry , binutils@sources.redhat.com In-Reply-To: <20020116213233.818F22264C@paris.ACT-Europe.FR> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-SW-Source: 2002-01/txt/msg00337.txt.bz2 --- Pascal Obry wrote: > > > Larger reserves limited the number of threads you could start. The > > MSVC compiler had a much smaller reserve than Cygwin before the patch. > > Right, but this has the bad consequence to break some non-threaded > programs. It was always possible to change the default stack size on the > command line. It still is. Of course this is also true for non-threaded programs, but > I > think that most of the programs around us do not use threads. > > Even on the Ada world, where tasking is part of the language, we have > many > programs that do not use tasks (threads), and those who do does not have > enough tasks to break the limit (which is around 35 if my memory > is right). > > Pascal Obry. Well, what should the default be? I chose 2 MB because: 1) Default of native compiler is 1 MB. Inspection of apps built by other W32 comilers indicates they have similar or smaller default stack reserve. 1 MB, however, is not sufficient to bootstrap GCC. 2 MB is. 2) Threads (and fibers). Although CreateThread allows user to set stack size, if size is smaller than default, the new thread uses the same size as the calling thread. With fibers, it is not possible to specify stack reserve; the size of the calling thread is always used. Apps that use fibers ("lightweight threads") can often (try to) create a 100 or more. The larger the stack reserve, the more likely that illegitimate __stdcall/__cdecl fixups will go undetected. One way that this can happen is to compile C code with -mrtd. Library functions that are not marked as __cdecl in headers will also be treated as stdcall. Sooner or later the stack will overflow. Better sooner than later. Danny http://my.yahoo.com.au - My Yahoo! - It's My Yahoo! Get your own!