🚀 go-pugleaf

In article <1992Aug07.185323.67191@ans.net> db3l@ans.net (David Bolen) writes:
>In article <713061696snx@ananke.stgt.sub.org> ak@ananke.stgt.sub.org (Andreas Kaiser) writes:
>
>>Why did IBM implement a fixed stack size in IBM C? Since OS/2 2.0
>>provides a paged memory management, there should be no reason not to
>>let the stack grow automatically. EMX does it this way. There is just
>>one single disadvantage: to notice an endless recursion, you have to
>>listen to the sound of your disk drive. But you don't have to count
>>stack bytes.
>
>It's only true for the primary thread of an application.  Any threads that
>you created under C Set/2 with the beginthread() call it set up with a
>maximum stack size, and the compiler handles guard page exceptions in
>order to commit additional stack space as necessary, up the maximum specified
>when the thread was created.
>
>I don't know why the primary thread doesn't do this as well, unless it's
>an OS/2 thing for the primary thread of an executable... I'm not that
>familiar with EMX - could it be creating an extra thread right off the bat
>to run the program in?
>
>--
>-- David
>--

The fixed stack size is imposed by OS/2.  Each stack is a memory
object, and memory objects cannot grow in size.  However, you can
set aside as much address space as you want for a stack.  The
primary thread's stack size is determined the EXE header, and can be
set by LINK386 or EXEHDR.  Secondary thread stack sizes are
determined by the beginthread() call.

It's not clear to me how EMX works around this limitation, if
indeed it does.  Maybe it specifies a humongous stack size.

This is one major difference between the primary thread's stack and
secondary threads' stacks:  the primary stack is initially committed,
while secondary stacks may be created either committed or uncommitted.
The guard page technique is needed only for the uncommitted case.  In
either case, the stack has a fixed upper size.
-- 

==============================================================================
Jeff Cohen         | Standard disclaimer:  My views are my own and may or may
jeffc@netcom.com   |                       not represent the views of IBM.
==============================================================================