-=> Quoting Jonathan de Boyne Pollard to Doug Nazar <=- 

 DN>
 > Do you know if Borland's _beginthread() uses the
 > STACK_SPARSE or STACK_COMMITED flag to DosCreateThread?
 DN>

 BP> over again.  I suspect that what I am about to say about Borland C++
 BP> for OS/2 will spawn the same long thread that it did last time that I
 BP> said it.
 BP> Borland C++ 2.0 for OS/2 does not generate stack probes.



 BP> Borland's "fix" for this is sheer laziness, and actually results in
 BP> a pretty severe performance penalty.  Rather than correcting the code
 BP> generator to generate stack probes in function prologues, the fix is
 BP> a replacement for Borland's static and dynamic runtime libraries that
 BP> replaces the existing _beginthread call with one that uses
 BP> STACK_COMMITTED instead of STACK_SPARSE.

Do you have the static runtime patch?  I have the dynamic version, and
I'd like to get the static version, if possible.

 BP> So a thread that is given 1Mb of stack in the call to _beginthread,
 BP> but that in practice rarely uses more than 16Kb, will only use four
 BP> pages of memory for its stack when compiled with Watcom C++, MetaWare
 BP> High C++, or IBM VisualAge C++.

 BP> When compiled with Borland C++ 2.0 for OS/2 with the fix applied,
 BP> however, that thread will use all 256 pages (1Mb) of memory for its
 BP> stack.

Seems like choosing a stack size that is closer the the threads actual
stack requirements would minimize this problem.

I usually start my threads with a 16k or 32k stack, then if I start
having problems, I raise the stack until the problem disappears.  True
it would be easier to call _beginthread() with a 1MB stack and let the
compiler handle it.  But it is a problem that can be worked around. :-)

Phil - Fido:  1:124/8014.0 | Internet:  pcrown{at}airmail.net

--- Blue Wave/OS2 v2.30