From:	W DOT Derks AT nl DOT cis DOT philips DOT com ("wiljan")
Subject:	Re: stack size (was Re[2]: serious bug with CYGNUS GCC b16)
5 Dec 1996 15:04:35 -0800 :
Sender:	daemon AT cygnus DOT com
Approved:	cygnus DOT gnu-win32 AT cygnus DOT com
Distribution:	cygnus
Message-ID:	<199612052049.VAA04194.cygnus.gnu-win32@nl.cis.philips.com>
Mime-Version:	1.0
Original-To:	<gnu-win32 AT cygnus DOT com>, "Sean McNeil" <mcneils AT applique DOT sedd DOT trw DOT com>
X-MSMail-Priority:	Normal
X-Priority:	3
X-Mailer:	Microsoft Internet Mail 4.70.1155
Original-Sender:	owner-gnu-win32 AT cygnus DOT com

Hello Sean,

You wrote:
> This explains a question I was getting ready to pose.  Apparantly, gcc
> adds stack probing whenever allocating large (>4k) space on the stack.
> I thought that this would extend the stack.  I guess it does assist in
> doing so by increments of sizecommit, but will not extend past
> sizereserve.  So, I need to set the sizereserve to something nice and
> large.  As mentioned, this is done with the -stack option to ld and can
> be made a default option when linking with gcc.
Do not make it to large. There is another trade of to take when using
threads.
A while ago I run into a problem that I was not able to create more then
125
threads on nt (using gnat304a of course). I had not idea what caused this.
A while later and giving it some thoughts when strugling with the linker
options
I came to the conclusion that for every thread such a piece of memory is
reserved.
Originally Labtek had the stack reserve size on hex 100 0000. Note that the
maximum userspace is 2 0000 0000 hex. This means that when having stacks
reserved for this size there is only room for 128 stacks.
I changed the stack reserve size to a much lower amount.
After that I was able to create much more threads (tasks) then before.

Wiljan

-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -