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,ca9eef4d5e2078ea
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Beware: Rep spec on an enumeration type causes code explosion
Date: 1997/12/06
Message-ID: <dewar.881426698@merv>#1/1
X-Deja-AN: 295784217
References: <gwinn-0512972303070001@dh5055063.res.ray.com>
 <EKrsrr.LD7.0.-s@inmet.camb.inmet.com>
X-Complaints-To: usenet@news.nyu.edu
X-Trace: news.nyu.edu 881426834 11284 (None) 128.122.140.58
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-12-06T00:00:00+00:00
List-Id: <comp.lang.ada>


Tucker said

<<We have versions of our runtime which only use the heap "implicitly"
for task control blocks (and these are recycled explicitly rather than
using free) and for task stacks (and again, these are recycled rather
than using free).  So the only calls on "free" should be in response
to an explicit call on an instance of unchecked-deallocation.  Furthermore,
we also have our own implementation of malloc/free which uses
"quick fit" rather than the traditional C "first fit."  This may
be the algorithm
>>


A useful idea would be to have a specific overridable storage pool that
can be used for task stack creation, something like

for task'Task_Storage_Pool use storage pool

actually it seems like it would be perfectly reasonable to allow the
extension of the standard Storage_Pool attribute for this:

for task'Storage_Pool use ...

where task is a task object or task type???