From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,88c97d669795535a,start
X-Google-Attributes: gid103376,public
From: Michael Rowley <rowley@intermetrics.com>
Subject: Re: What task storage_size to use?
Date: 1997/11/23
Message-ID: <34785EC5.740B76B0@intermetrics.com>#1/1
X-Deja-AN: 291930431
Sender: news@inmet.camb.inmet.com (USENET news)
X-Nntp-Posting-Host: piglet.camb.inmet.com
References: <3472A748.213DF2CA@intermetrics.com>
 <3.0.1.32.19971121191820.00b96cf0@spectre.mitre.org>
To: "Robert I. Eachus" <eachus@mitre.org>
Organization: Intermetrics, Inc.
Newsgroups: comp.lang.ada
Date: 1997-11-23T00:00:00+00:00
List-Id: <comp.lang.ada>


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