Re: What task storage_size to use?

[Michael Rowley <rowley@intermetrics.com>]

This thread may be of interest to people other than Gnat users, so I am
cross-posting from the Gnat chat mailing list, where it started, to the
comp.lang.ada newsgroup.

The topic regards trying to determine the appropriate Storage_Size to
use for a stack, possibly assuming that the programmer already knows
what the frame stack will look like when it is the deepest (i.e. what
function calls are on it).

Robert I. Eachus wrote:
> 
> At 04:24 PM 11/19/97 +0100, CHARLET Arnaud wrote:
> >In the current version of gdb for GNAT, this problem is very easy
> >to solve since gdb gives you the stack size and % of stack used for each
> >task.
> 
>    Which gives a useful number in many cases.  However, as Mike Brenner was
> saying, the halting problem can be embedded in the general case.  If those
> words don't mean anything to you, translate it as "well beyond impossible."

I think I like Arno's answer better.  His answer implies that I should
run my program such that tasks are running as large a frame stack as I
think they will ever encounter, then look at GDB to determine that size,
and possibly choose a larger number.

Robert's answer is less useful.  Knowing it's impossible to determine
the maximum size in general (which isn't news), doesn't help me.  Does
it mean I shouldn't use tasks?  Does it mean I should just use the
default task storage_size, and then if I run the program and find that
stack overflow is overwriting non-stack memory, I should then up the
stack size and try again?

Another approach that I am thinking of using is to create my own
Storage_Pool for the task access type, which would allocate one more
page than necessary for the task and write protect the extra page.  Then
if there is a page fault on that page I would know that I am within one
page of running out of stack space, and then try to recover gracefully.

Michael Rowley
rowley@inmet.com