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,5997b4b7b514f689
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Reading a line of arbitrary length
Date: 1997/02/15
Message-ID: <dewar.856015177@merv>#1/1
X-Deja-AN: 218979981
References: <5ds40o$rpo@fg70.rz.uni-karlsruhe.de> <33032AE2.666F@mds.lmco.com>
 <dewar.855848896@merv> <33037A74.44AF@mds.lmco.com>
 <330481C5.5096@elca-matrix.ch>
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-02-15T00:00:00+00:00
List-Id: <comp.lang.ada>


Mats said

<<Wrong, the heap is generally global with respect to tasks, and it has to
be that way in this case because the type String_Access is a global
access type, potentially visible from any task.>>

There is no issue of visibility here, just because an access type is
visible to more than one task does not mean that it has to be allocated
in a global heap. Indeed, a very reasonable approach for *all* allocation
activity is to allocate from task local sub-storage pools to avoid the
expense of global task locking for allocation. This approach is quite
general, and applies to general and pool-specific access types.

You do have to be careful about unchecked_deallocation, but there are
completely safe algorithms that handle this case without locking as
well.

We have quite carefully considered approaches of this kind, especially
in the context of unbounded strings handling.