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

  I've several times considered creating a digest of some of the topics
  that we have discussed here in OS2PROG, partly to form a Frequently
  Given Answers document that people can refer to, and partly so that we
  don't end up having the same discussions over and over again.  I suspect
  that what I am about to say about Borland C++ for OS/2 will spawn the
  same long thread that it did last time that I said it.

  Borland C++ 2.0 for OS/2 does not generate stack probes.

  On OS/2, a thread's stack is expanded by use of a guard page at the
  bottom of all of the pages currently committed.  When this guard page is
  referenced, the OS/2 kernel commits another page to the stack, and
  creates a new guard page 4Kb lower down the stack.

  Referencing the stack *below* the guard page is an error (since such a
  reference could be a wild pointer, and nothing to do with the stack at
  all), and so the OS/2 kernel generates an exception rather than
  auto-expanding the stack.

  A C++ function that has more than 4Kb of local data must thus ensure
  that it "touches" the stack in 4Kb increments in its function prologue,
  so that the guard page mechanism kicks in and commits as many pages as
  are required for the local data.  All of the 32-bit OS/2 C++ compilers
  generate code to do this in their function prologues.

  All of them except Borland C++ 2.0 for OS/2, that is.  It's as
  fundamental a part of generating code for OS/2 as generating thunking
  prologues for __export functions is for Windows.  But Borland C++ simply
  doesn't do it.  Many people have commented that this is hardly a
  surprise, given the dire quality of the rest of Borland's code
  generator.

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

  A common practice on OS/2 is to use huge stack sizes for secondary
  threads if you don't want to be bothered by stack problems.  The guard
  page mechanism will ensure that the OS/2 kernel only commits as many
  stack pages as are actually used.

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

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

  As I, and others, have said in the past, Borland C++ 2.0 for OS/2 is
  just no good for writing multithreaded programs.

  > JdeBP <
___
 X MegaMail 2.10 #0:
--- Maximus/2 3.01