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
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: What task storage_size to use?
Date: 1997/11/24
Message-ID: <dewar.880355244@merv>#1/1
X-Deja-AN: 292073614
References: <3472A748.213DF2CA@intermetrics.com>
 <3.0.1.32.19971121191820.00b96cf0@spectre.mitre.org>
 <34785EC5.740B76B0@intermetrics.com>
 <mheaney-ya023680002311971911160001@news.ni.net>
X-Complaints-To: usenet@news.nyu.edu
X-Trace: news.nyu.edu 880355322 9018 (None) 128.122.140.58
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-11-24T00:00:00+00:00
List-Id: <comp.lang.ada>


Matthew replies

<<>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.

I don't get it.  Why don't you just catch Storage_Error?
>>


Indeed, and that is in fact *how* GNAT implements the check for
Storage_Error with respect to stack allocation!