CVS difference for ai05s/ai05-0111-3.txt
--- ai05s/ai05-0111-3.txt 2011/04/28 07:01:31 1.12
+++ ai05s/ai05-0111-3.txt 2011/06/18 07:18:33 1.13
@@ -1,12 +1,18 @@
-!standard 4.8(2) 11-04-28 AI05-0111-3/10
+!standard 4.8(2) 11-06-17 AI05-0111-3/11
!standard 4.8(3/2)
+!standard 4.8(5/2)
!standard 4.8(10.3/2)
!standard 13.11(16/3)
-!standard 13.11.4 (0)
-!standard 13.11.5 (0)
-!standard 13.11.6 (0)
+!standard 13.11(38)
+!standard 13.11(39/1)
+!standard 13.11(41)
+!standard 13.11(43)
+!standard 13.11.4(0)
+!standard 13.11.5(0)
+!standard 13.11.6(0)
!class Amendment 10-10-13
-!status Amendment 2012 11-03-11
+!status Amendment 2012 11-06-11
+!status ARG Approved (by Letter Ballot) 7-1-3 11-05-16
!status work item 11-04-11
!status ARG Approved 8-0-0 11-02-18
!status work item 10-10-13
@@ -76,15 +82,15 @@
Add after 4.8(5/2):
- If a subpool_specification is given, the storage pool of the access type
- shall be a descendant of Root_Storage_Pool_with_Subpools.
+ If a subpool_specification is given, the type of the storage pool of the
+ access type shall be a descendant of Root_Storage_Pool_With_Subpools.
Add after 4.8(10.3/2):
If the allocator includes a *subpool_handle_*name, Constraint_Error is
- raised if the subpool is null. Program_Error is raised if the subpool does
- not *belong* (see 13.11.4) to the storage pool of the access type of the
- allocator.
+ raised if the subpool handle is null. Program_Error is raised if the
+ subpool does not *belong* (see 13.11.4) to the storage pool of the
+ access type of the allocator.
AARM Implementation Note: This can be implemented by comparing the result of
Pool_of_Subpool to a reference to the storage pool object. Pool_of_Subpool's
@@ -94,7 +100,7 @@
no pool at all. This includes detecting dangling subpool handles so long as the
subpool object (the object designated by the handle) still exists. (If the
subpool object has been deallocated, execution is erroneous; it is likely that
- this check will still detect the problem, but there cannot be a guarentee.)
+ this check will still detect the problem, but there cannot be a guarantee.)
Add after 7.6.1(20):
@@ -138,88 +144,56 @@
package System.Storage_Pools.Subpools is
pragma Preelaborate (Subpools);
- type Root_Storage_Pool_with_Subpools is
+ type Root_Storage_Pool_With_Subpools is
abstract new Root_Storage_Pool with private;
- -- An access type must have a storage pool of a type
- -- descended from this type to use subpools.
type Root_Subpool is abstract tagged limited private;
- -- The subpool object type. Objects of this type are managed by
- -- the storage pool; usually only the handles are exposed
- -- to clients.
type Subpool_Handle is access all Root_Subpool'Class;
for Subpool_Handle'Storage_Size use 0;
- -- This provides a reference to a subpool, and serves to identify
- -- the subpool within the program.
- function Create_Subpool(Pool : in out Root_Storage_Pool_with_Subpools)
+ function Create_Subpool(Pool : in out Root_Storage_Pool_With_Subpools)
return not null Subpool_Handle is abstract;
- -- Create subpool within given storage pool.
- -- NOTE: Additional functions that create subpools may be
- -- defined for a given storage pool that supports subpools.
- -- [Editor's Note: This uses AI05-0143-1 to allow an in out parameter; "access"
- -- could be used instead but would be less convenient.]
- -- Will typically call Set_Pool_of_Subpool, so the newly created
- -- subpool belongs to Pool.
function Pool_of_Subpool(Subpool : not null Subpool_Handle)
- return access Root_Storage_Pool_with_Subpools'Class;
- -- Return access to the storage pool the Subpool belongs to.
+ return access Root_Storage_Pool_With_Subpools'Class;
procedure Set_Pool_of_Subpool(Subpool : not null Subpool_Handle;
- To : in out Root_Storage_Pool_with_Subpools'Class);
- -- Causes the Subpool to belong to the given pool.
- -- This is intended to be called from Create_Subpool or similar
- -- subpool constructors.
- -- Raises Program_Error if the Subpool already belongs to a pool.
+ To : in out Root_Storage_Pool_With_Subpools'Class);
procedure Allocate_From_Subpool(
- Pool : in out Root_Storage_Pool_with_Subpools;
+ Pool : in out Root_Storage_Pool_With_Subpools;
Storage_Address : out Address;
Size_In_Storage_Elements : in Storage_Elements.Storage_Count;
Alignment : in Storage_Elements.Storage_Count;
Subpool : not null Subpool_Handle) is abstract
with Pre'Class => Pool_of_Subpool(Subpool) = Pool'Access;
- -- Allocate space from specified subpool.
- -- [Editor's note: The precondition is as described in AI05-0145-2 and
- -- AI05-0183-1. It could be omitted if necessary.]
procedure Deallocate_Subpool(
- Pool : in out Root_Storage_Pool_with_Subpools;
+ Pool : in out Root_Storage_Pool_With_Subpools;
Subpool : in out Subpool_Handle) is abstract
with Pre'Class => Pool_of_Subpool(Subpool) = Pool'Access;
- -- Deallocate the space for all of the objects allocated from the
- -- specified subpool. Unchecked_Deallocate_Subpool calls this.
function Default_Subpool_for_Pool(
- Pool : in Root_Storage_Pool_with_Subpools) return not null Subpool_Handle;
- -- Returns a handle of the default subpool for Pool.
- -- This version raises Program_Error; it should be overridden for
- -- types that wish to support default subpools (that is, allocators
- -- without a subpool_specification).
+ Pool : in Root_Storage_Pool_With_Subpools) return not null Subpool_Handle;
overriding
procedure Allocate(
- Pool : in out Root_Storage_Pool_with_Subpools;
+ Pool : in out Root_Storage_Pool_With_Subpools;
Storage_Address : out Address;
Size_In_Storage_Elements : in Storage_Elements.Storage_Count;
Alignment : in Storage_Elements.Storage_Count);
- -- Normally not used.
overriding
procedure Deallocate(
- Pool : in out Root_Storage_Pool_with_Subpools;
+ Pool : in out Root_Storage_Pool_With_Subpools;
Storage_Address : in Address;
Size_In_Storage_Elements : in Storage_Elements.Storage_Count;
Alignment : in Storage_Elements.Storage_Count) is null;
- -- Normally, concrete types will inherit this null version.
overriding
- function Storage_Size (Pool : Root_Storage_Pool_with_Subpools)
+ function Storage_Size (Pool : Root_Storage_Pool_With_Subpools)
return Storage_Count is (Storage_Elements.Storage_Count'Last);
- -- This can be overridden if there is a limit.
- -- [Editor's note: This is an expression function; see AI05-0177-1.]
private
... -- not specified by the language
@@ -229,14 +203,45 @@
A *subpool* is a separately reclaimable portion of a storage pool, identified by
an object of type Subpool_Handle (a *subpool handle*). A subpool handle also
identifies the enclosing storage pool, a *storage pool that supports subpools*,
-which is a storage pool whose type is descended from Root_Storage_Pool_with_Subpools.
+which is a storage pool whose type is descended from
+Root_Storage_Pool_With_Subpools. A subpool is created by calling Create_Subpool
+or a similar constructor; the constructor returns the subpool handle.
+
+A *subpool object* is an object of a type descended from Root_Subpool_Type.
+Redundant[Typically, subpool objects are managed by the containing storage
+pool; only the handles need be exposed to clients of the storage pool.
+Subpool objects are designated by subpool handles, and are the run-time
+representation of a subpool.]
+
+Each subpool *belongs* to a single storage pool (which will always be a pool
+that supports subpools). An access to the pool that a subpool belongs to can
+be obtained by calling Pool_of_Subpool with the subpool handle.
+Set_Pool_of_Subpool causes the subpool of the subpool handle to belong to the
+given pool@Redundant[; this is intended to be called from subpool constructors
+like Create_Subpool.] Set_Pool_of_Subpool propagates Program_Error if the
+subpool already belongs to a pool.
+
+AARM Discussion: Pool_of_Subpool and Set_Pool_of_Subpool are provided by the
+Ada implementation and typically will not be overridden by the pool implementer.
+
When an allocator for a type whose storage pool supports subpools is evaluated,
a call is made on Allocate_From_Subpool passing in a Subpool_Handle, in addition
-to the parameters as defined for calls on Allocate (see 13.11).
-The subpool denoted by the *subpool_handle_*name is used, if specified in an
-allocator. Otherwise, Default_Subpool_for_Pool of the Pool is used.
-All requirements on the Allocate procedure also apply to Allocate_from_Subpool.
+to the parameters as defined for calls on Allocate (see 13.11). The subpool
+denoted by the *subpool_handle_*name is used, if specified in an allocator.
+Otherwise, Default_Subpool_for_Pool of the Pool is used to provide a subpool
+handle. All requirements on the Allocate procedure also apply to
+Allocate_from_Subpool.
+
+AARM Discussion:
+
+Deallocate_Subpool is expected to do whatever is needed to deallocate all of
+the objects contained in the subpool; it is called
+from Unchecked_Deallocate_Subpool (see 13.11.5).
+
+Typically, the pool implementer will not override Allocate.
+End AARM Discussion.
+
Legality Rules
If a storage pool that supports subpools is specified as the Storage_Pool for
@@ -263,10 +268,10 @@
A call to Subpools.Allocate(P, Addr, Size, Align) does the following:
Allocate_From_Subpool
- (Root_Storage_Pool_with_Subpools'Class(P),
+ (Root_Storage_Pool_With_Subpools'Class(P),
Addr, Size, Align,
Subpool => Default_Subpool_for_Pool
- (Root_Storage_Pool_with_Subpools'Class(P)));
+ (Root_Storage_Pool_With_Subpools'Class(P)));
An allocator that allocates in a subpool raises Program_Error if the allocated
@@ -277,6 +282,8 @@
gained. At this time, we are unable to come up with a set of rules for task
termination that is both useful, and surely feasible to implement.
+Unless overridden, Default_Subpool_for_Pool propagates Program_Error.
+
Implementation Permissions
When an allocator for a type whose storage pool is of type
@@ -295,18 +302,50 @@
- The implementation can declare Allocate_From_Subpool as a primitive of
Root_Storage_Pool in the private part of Storage_Pools. This means that
- the Allocate_From_Subpool for Root_Storage_Pool_with_Subpools overrides
+ the Allocate_From_Subpool for Root_Storage_Pool_With_Subpools overrides
that private one. The implementation can thus call the private one,
which will call Allocate for non-subpool-supporting pools. The effect
of this implementation does not change if Allocate is overridden for
a pool that supports subpools.
[end AARM Reason]
+NOTES:
+
+ + A user-defined storage pool type that supports subpools can be
+ implemented by extending the Root_Storage_Pool_With_Subpools
+ type, and overriding the primitive subprograms Create_Subpool,
+ Allocate_From_Subpool, and Deallocate_Subpool. Create_Subpool
+ should call Set_Pool_Of_Subpool before returning the subpool
+ handle. To make use of such a pool, a user would declare an
+ object of the type extension, use it to define the Storage_Pool
+ attribute of one or more access types, and then call
+ Create_Subpool to obtain subpool handles associated with the
+ pool.
+
+ + A user-defined storage pool type that supports subpools may define
+ additional subpool constructors similar to Create_Subpool (these
+ typically will have additional parameters).
+
+ + The pool implementor should override Default_Subpool_For_Pool
+ if the pool is to support a default subpool for the pool. The
+ implementor can override Deallocate if individual object reclamation
+ is to be supported, and can override Storage_Size if there is some
+ limit on the total size of the storage pool. The implementor can
+ override Initialize and Finalize if there is any need for non-trivial
+ initialization and finalization for the pool as a whole. For
+ example, Finalize might reclaim blocks of storage that are
+ allocated over and above the space occupied by the pool object
+ itself. The pool implementor may extend the Root_Subpool
+ type as necessary to carry additional information with each
+ subpool provided by Create_Subpool.
+
+
13.11.5 Subpool Reclamation
The following language-defined library procedure exists:
- procedure Ada.Unchecked_Deallocate_Subpool
+ with System.Storage_Pools.Subpools;
+ procedure Ada.Unchecked_Deallocate_Subpool
(Subpool : in out System.Storage_Pools.Subpools.Subpool_Handle);
A subpool may be explicitly deallocated using Unchecked_Deallocate_Subpool.
@@ -324,8 +363,8 @@
* The following Redundant[dispatching] call is then made:
Deallocate_Subpool(Pool_of_Subpool(Subpool).all, Subpool);
-Finalization of a Root_Storage_Pool_with_Subpools finalizes all subpools
-that have not yet been finalized.
+Finalization of a Root_Storage_Pool_With_Subpools object finalizes all subpools
+that belong to that pool that have not yet been finalized.
AARM Discussion:
@@ -373,7 +412,7 @@
subtype Subpool_Handle is Subpools.Subpool_Handle;
type Mark_Release_Pool_Type (Pool_Size : Storage_Count) is new
- Subpools.Root_Storage_Pool_with_Subpools with private;
+ Subpools.Root_Storage_Pool_With_Subpools with private;
function Mark (Pool : in out Mark_Release_Pool_Type)
return not null Subpool_Handle;
@@ -390,7 +429,7 @@
type Subpool_Array is array (Subpool_Indexes) of aliased MR_Subpool;
type Mark_Release_Pool_Type (Pool_Size : Storage_Count) is new
- Subpools.Root_Storage_Pool_with_Subpools with record
+ Subpools.Root_Storage_Pool_With_Subpools with record
Storage : Storage_Array (1 .. Pool_Size);
Next_Allocation : Storage_Count := 1;
@@ -512,18 +551,24 @@
As usual, a derivative of Root_Storage_Pool may define additional operations.
For example, [presuming that]{consider the} Mark_Release_Pool_Type {defined in
-13.11.5, that} has two additional operations, Mark and Release, the following is
+13.11.6, that} has two additional operations, Mark and Release, the following is
a possible use:
Delete the Block_Size discriminant from 13.11(39/1), and add a comment "As
-defined in 13.11.5".
+defined in package MR_Pool, see 13.11.6".
-Delete the Block_Size discriminant from 13.11(41), and add after it:
-My_Mark : MR_Pool.Subpool_Handle; -- See 13.11.5
+Replace 13.11(41) with
+
+Our_Pool : Mark_Release_Pool_Type (Pool_Size => 2000);
+My_Mark : MR_Pool.Subpool_Handle; -- See 13.11.6
+
+Modify 13.11(42):
+...use [MR_Pool]{Our_Pool};
+
Replace 13.11(43) with:
-My_Mark := Mark(MR_Pool);
+My_Mark := Mark(Our_Pool);
... -- Allocate objects using "new (My_Mark) Designated(...)"
Release(My_Mark); -- Finalize objects and reclaim storage.
@@ -535,7 +580,7 @@
extended. So the implementor of the storage pool can keep some information
in a per-subpool data structure (by extending Root_Subpool), and some
globally for the overall storage pool (by extending
-Root_Storage_Pool_with_Subpools).
+Root_Storage_Pool_With_Subpools).
Meanwhile, the "root part" of the subpool object type will be used by
the Ada implementation to implement finalization for the subpools,
@@ -685,6 +730,492 @@
separately reclaimable item, namely one for each customer historical record,
one for each product description, and one for each shopping cart.
+!corrigendum 4.8(2)
+
+@drepl
+@xcode<@fa<allocator ::=
+ >@ft<@b<new>>@fa< subtype_indication | >@ft<@b<new>>@fa< qualified_expression>>
+@dby
+@xcode<@fa<allocator ::=
+ >@ft<@b<new>>@fa< [subpool_specification] subtype_indication
+ | >@ft<@b<new>>@fa< [subpool_specification] qualified_expression>>
+
+@xcode<@fa<subpool_specification ::= (>@ft<@i<subpool_handle_>>@fa<name)>>
+
+!corrigendum 4.8(3/1)
+
+@drepl
+The expected type for an @fa<allocator> shall be a single access-to-object type with
+designated type @i<D> such that either @i<D> covers the type determined by the
+@fa<subtype_mark> of the @fa<subtype_indication> or @fa<qualified_expression>,
+or the expected type is anonymous and the determined type is @i<D>'Class.
+@dby
+The expected type for an @fa<allocator> shall be a single access-to-object type with
+designated type @i<D> such that either @i<D> covers the type determined by the
+@fa<subtype_mark> of the @fa<subtype_indication> or @fa<qualified_expression>,
+or the expected type is anonymous and the determined type is @i<D>'Class.
+A @i<subpool_handle_>@fa<name> is expected to be of any type descended from
+Subpool_Handle, the type used to identify a subpool, declared in package
+System.Storage_Pools.Subpools (see 13.11.4).
+
+!corrigendum 4.8(5/2)
+
+@dinsa
+If the type of the @fa<allocator> is an access-to-constant type, the
+@fa<allocator> shall be an initialized allocator.
+@dinst
+If a @fa<subpool_specification> is given, the type of the storage pool of the
+access type shall be a descendant of Root_Storage_Pool_With_Subpools.
+
+!corrigendum 4.8(10.3/2)
+
+@dinsa
+If the object to be created by an @fa<allocator> contains any tasks, and the
+master of the type of the @fa<allocator> is completed, and all of the dependent
+tasks of the master are terminated (see 9.3), then Program_Error is raised.
+@dinst
+If the @fa<allocator> includes a @i<subpool_handle_>@fa<name>, Constraint_Error is
+raised if the subpool handle is @b<null>. Program_Error is raised if the
+subpool does not @i<belong> (see 13.11.4) to the storage pool of the
+access type of the @fa<allocator>.
+
+!corrigendum 7.6.1(20)
+
+@dinsa
+@xbullet<For a Finalize invoked by a transfer of control due to an abort or selection
+of a terminate alternative, the exception is ignored; any other finalizations due to
+be performed are performed.>
+@dinst
+@s8<@i<Implementation Permissions>>
+
+The implementation may finalize objects created by @fa<allocator>s for an access type
+whose storage pool supports subpools (see 13.11.4) as if the objects were created
+(in an arbitrary order) at the point where the storage pool was elaborated instead
+of the first freezing point of the access type.
+
+!corrigendum 13.11(16)
+
+@drepl
+An @fa<allocator> of type T allocates storage from T's storage pool. If the storage pool
+is a user-defined object, then the storage is allocated by calling Allocate, passing
+T'Storage_Pool as the Pool parameter. The Size_In_Storage_Elements parameter indicates
+the number of storage elements to be allocated, and is no more than D'Max_Size_In_Storage_Elements,
+where D is the designated subtype. The Alignment parameter is D'Alignment. The result returned
+in the Storage_Address parameter is used by the @fa<allocator> as the address of the
+allocated storage, which is a contiguous block of memory of Size_In_Storage_Elements storage
+elements. Any exception propagated by Allocate is propagated by the @fa<allocator>.
+@dby
+An @fa<allocator> of a type @i<T> that does not support subpools allocates storage from
+@i<T>'s storage pool. If the storage pool is a user-defined object, then the storage is
+allocated by calling Allocate as described below. @fa<Allocator>s for types that support
+subpools are described in 13.11.4.
+
+!corrigendum 13.11(38)
+
+@drepl
+As usual, a derivative of Root_Storage_Pool may define additional operations.
+For example, presuming that Mark_Release_Pool_Type has two additional operations,
+Mark and Release, the following is a possible use:
+@dby
+As usual, a derivative of Root_Storage_Pool may define additional operations.
+For example, [presuming that]{consider the} Mark_Release_Pool_Type {defined in
+13.11.6, that} has two additional operations, Mark and Release, the following is
+a possible use:
+
+!corrigendum 13.11(39/1)
+
+@drepl
+@xcode<@b<type> Mark_Release_Pool_Type
+ (Pool_Size : Storage_Elements.Storage_Count;
+ Block_Size : Storage_Elements.Storage_Count)
+ @b<is new> Root_Storage_Pool @b<with private>;>
+@dby
+@xcode<@b<type> Mark_Release_Pool_Type
+ (Pool_Size : Storage_Elements.Storage_Count)
+ @b<is new> Root_Storage_Pool @b<with private>;
+ -- @i<@ft<As defined in package MR_Pool, see 13.11.6>>>
+
+!corrigendum 13.11(41)
+
+@drepl
+@xcode<MR_Pool : Mark_Release_Pool_Type (Pool_Size =@> 2000,
+ Block_Size =@> 100);>
+@dby
+@xcode<Our_Pool : Mark_Release_Pool_Type (Pool_Size =@> 2000);
+My_Mark : MR_Pool.Subpool_Handle>
+
+!corrigendum 13.11(42)
+
+@drepl
+@xcode<@b<type> Acc @b<is> @b<access> ...;
+@b<for> Acc'Storage_Pool @b<use> MR_Pool;
+...>
+@dby
+@xcode<@b<type> Acc @b<is> @b<access> ...;
+@b<for> Acc'Storage_Pool @b<use> Our_Pool;
+...>
+
+!corrigendum 13.11(43)
+
+@drepl
+@xcode<Mark(MR_Pool);
+... -- @i<@ft<Allocate objects using "@b<new> Designated(...)">>
+Release(MR_Pool); -- Reclaim the storage.>
+@dby
+@xcode<My_Mark := Mark(MR_Pool);
+... -- @i<@ft<Allocate objects using "@b<new> (My_Mark) Designated(...)">>
+Release(My_Mark); -- Finalize objects and reclaim storage.>
+
+!corrigendum 13.11.4(0)
+
+@dinsc
+
+This subclause defines a package to support the partitioning of a
+storage pool into subpools. A subpool may be specified as the default to
+be used for allocation from the associated storage pool, or a particular
+subpool may be specified as part of an @fa<allocator> (see 4.8).
+
+@i<@s8<Static Semantics>>
+
+The following language-defined library package exists:
+
+@xcode<@b<package> System.Storage_Pools.Subpools @b<is>
+ @b<pragma> Preelaborate (Subpools);>
+
+@xcode< @b<type> Root_Storage_Pool_With_Subpools @b<is>
+ @b<abstract new> Root_Storage_Pool @b<with private>;>
+
+@xcode< @b<type> Root_Subpool @b<is abstract tagged limited private>;>
+
+@xcode< @b<type> Subpool_Handle @b<is access all> Root_Subpool'Class;
+ @b<for> Subpool_Handle'Storage_Size @b<use> 0;>
+
+@xcode< @b<function> Create_Subpool (Pool : @b<in out> Root_Storage_Pool_With_Subpools)
+ @b<return not null> Subpool_Handle @b<is abstract>;>
+
+@xcode< @b<function> Pool_of_Subpool (Subpool : @b<not null> Subpool_Handle)
+ @b<return access> Root_Storage_Pool_With_Subpools'Class;>
+
+@xcode< @b<procedure> Set_Pool_of_Subpool (Subpool : @b<not null> Subpool_Handle;
+ To : @b<in out> Root_Storage_Pool_With_Subpools'Class);>
+
+@xcode< @b<procedure> Allocate_From_Subpool (
+ Pool : @b<in out> Root_Storage_Pool_With_Subpools;
+ Storage_Address : @b<out> Address;
+ Size_In_Storage_Elements : @b<in> Storage_Elements.Storage_Count;
+ Alignment : @b<in> Storage_Elements.Storage_Count;
+ Subpool : @b<not null> Subpool_Handle) @b<is abstract>
+ @b<with> Pre'Class =@> Pool_of_Subpool(Subpool) = Pool'Access;>
+
+@xcode< @b<procedure> Deallocate_Subpool (
+ Pool : @b<in out> Root_Storage_Pool_With_Subpools;
+ Subpool : @b<in out> Subpool_Handle) @b<is abstract>
+ @b<with> Pre'Class =@> Pool_of_Subpool(Subpool) = Pool'Access;>
+
+@xcode< @b<function> Default_Subpool_for_Pool (
+ Pool : @b<in> Root_Storage_Pool_With_Subpools) @b<return not null> Subpool_Handle;>
+
+@xcode< @b<overriding>
+ @b<procedure> Allocate (
+ Pool : @b<in out> Root_Storage_Pool_With_Subpools;
+ Storage_Address : @b<out> Address;
+ Size_In_Storage_Elements : @b<in> Storage_Elements.Storage_Count;
+ Alignment : @b<in> Storage_Elements.Storage_Count);>
+
+@xcode< @b<overriding>
+ @b<procedure> Deallocate (
+ Pool : @b<in out> Root_Storage_Pool_With_Subpools;
+ Storage_Address : @b<in> Address;
+ Size_In_Storage_Elements : @b<in> Storage_Elements.Storage_Count;
+ Alignment : @b<in> Storage_Elements.Storage_Count) @b<is null>;>
+
+@xcode< @b<overriding>
+ @b<function> Storage_Size (Pool : Root_Storage_Pool_With_Subpools)
+ @b<return> Storage_Count @b<is> (Storage_Elements.Storage_Count'Last);>
+
+@xcode<@b<private>
+ ... -- @ft<@i<not specified by the language>>
+@b<end> System.Storage_Pools.Subpools;>
+
+A @i<subpool> is a separately reclaimable portion of a storage pool, identified by
+an object of type Subpool_Handle (a @i<subpool handle>). A subpool handle also
+identifies the enclosing storage pool, a @i<storage pool that supports subpools>,
+which is a storage pool whose type is descended from
+Root_Storage_Pool_With_Subpools. A subpool is created by calling Create_Subpool
+or a similar constructor; the constructor returns the subpool handle.
+
+A @i<subpool object> is an object of a type descended from Root_Subpool_Type.
+Typically, subpool objects are managed by the containing storage
+pool; only the handles need be exposed to clients of the storage pool.
+Subpool objects are designated by subpool handles, and are the run-time
+representation of a subpool.
+
+Each subpool @i<belongs> to a single storage pool (which will always be a pool
+that supports subpools). An access to the pool that a subpool belongs to can
+be obtained by calling Pool_of_Subpool with the subpool handle.
+Set_Pool_of_Subpool causes the subpool of the subpool handle to belong to the
+given pool; this is intended to be called from subpool constructors
+like Create_Subpool. Set_Pool_of_Subpool propagates Program_Error if the
+subpool already belongs to a pool.
+
+When an @fa<allocator> for a type whose storage pool supports subpools is evaluated,
+a call is made on Allocate_From_Subpool passing in a Subpool_Handle, in addition
+to the parameters as defined for calls on Allocate (see 13.11). The subpool
+denoted by the @i<subpool_handle_>@fa<name> is used, if specified in an @fa<allocator>.
+Otherwise, Default_Subpool_for_Pool of the Pool is used to provide a subpool
+handle. All requirements on the Allocate procedure also apply to
+Allocate_from_Subpool.
+
+@i<@s8<Legality Rules>>
+
+If a storage pool that supports subpools is specified as the Storage_Pool for
+an access type, the access type is called a @i<subpool access type>. A subpool
+access type shall be a pool-specific access type.
+
+The accessibility level of a subpool access type shall not be statically
+deeper than that of the storage pool object.
+
+@i<@s8<Dynamic Semantics>>
+
+When a subpool access type is frozen (see 13.14), a check is made that the
+accessibility level of the subpool access type is not deeper than that of
+the storage pool object. Program_Error is raised if this check fails.
+
+A call to Subpools.Allocate(P, Addr, Size, Align) does the following:
+
+@xcode<Allocate_From_Subpool
+ (Root_Storage_Pool_With_Subpools'Class(P),
+ Addr, Size, Align,
+ Subpool =@> Default_Subpool_for_Pool
+ (Root_Storage_Pool_With_Subpools'Class(P)));>
+
+An @fa<allocator> that allocates in a subpool raises Program_Error if the allocated
+object has task parts.
+
+Unless overridden, Default_Subpool_for_Pool propagates Program_Error.
+
+@i<@s8<Implementation Permissions>>
+
+When an allocator for a type whose storage pool is of type
+Root_Storage_Pool'Class is evaluated, but supports subpools, the
+implementation may call Allocate rather than Allocate_From_Subpool.
+This will have the same effect, so long as Allocate has not been
+overridden.
+
+@s9<NOTES@hr
+11 A user-defined storage pool type that supports subpools can be
+implemented by extending the Root_Storage_Pool_With_Subpools
+type, and overriding the primitive subprograms Create_Subpool,
+Allocate_From_Subpool, and Deallocate_Subpool. Create_Subpool
+should call Set_Pool_Of_Subpool before returning the subpool
+handle. To make use of such a pool, a user would declare an
+object of the type extension, use it to define the Storage_Pool
+attribute of one or more access types, and then call
+Create_Subpool to obtain subpool handles associated with the pool.>
+
+@s9<12 A user-defined storage pool type that supports subpools may define
+additional subpool constructors similar to Create_Subpool (these
+typically will have additional parameters).>
+
+@s9<13 The pool implementor should override Default_Subpool_For_Pool
+if the pool is to support a default subpool for the pool. The
+implementor can override Deallocate if individual object reclamation
+is to be supported, and can override Storage_Size if there is some
+limit on the total size of the storage pool. The implementor can
+override Initialize and Finalize if there is any need for non-trivial
+initialization and finalization for the pool as a whole. For
+example, Finalize might reclaim blocks of storage that are
+allocated over and above the space occupied by the pool object
+itself. The pool implementor may extend the Root_Subpool
+type as necessary to carry additional information with each
+subpool provided by Create_Subpool.>
+
+
+!corrigendum 13.11.5(0)
+
+@i<@s8<Static Semantics>>
+
+The following language-defined library procedure exists:
+
+@xcode<@b<with> System.Storage_Pools.Subpools;
+@b<procedure> Ada.Unchecked_Deallocate_Subpool
+ (Subpool : @b<in out> System.Storage_Pools.Subpools.Subpool_Handle);>
+
+A subpool may be explicitly deallocated using Unchecked_Deallocate_Subpool.
+
+If Subpool is @b<null>, a call on Unchecked_Deallocate_Subpool has no
+effect. Otherwise, the subpool is finalized, and Subpool is set to @b<null>.
+
+Finalization of a subpool has the following effects:
+
+@xbullet<The subpool no longer belongs to any pool;>
+
+@xbullet<Any of the objects allocated from the subpool that still exist
+are finalized in an arbitrary order;>
+
+@xbullet<The following dispatching call is then made:>
+
+@xindent<@fc< Deallocate_Subpool(Pool_of_Subpool(Subpool).@b<all>, Subpool);>>
+
+Finalization of a Root_Storage_Pool_With_Subpools object finalizes all subpools
+that belong to that pool that have not yet been finalized.
+
+
+!corrigendum 13.11.6(0)
+
+@i<@s8<Examples>>
+
+The following example is a simple but complete implementation of the classic
+Mark/Release pool using subpools:
+
+@xcode<@b<with> System.Storage_Pools.Subpools;
+@b<with> System.Storage_Elements;
+@b<with> Ada.Unchecked_Deallocate_Subpool;
+@b<package> MR_Pool @b<is>>
+
+@xcode< @b<use> System.Storage_Pools;
+ -- @ft<@i<For uses of Subpools.>>
+ @b<use> System.Storage_Elements;
+ -- @ft<@i<For uses of Storage_Count and Storage_Array.>>>
+
+@xcode< -- @ft<@i<Mark and Release work in a stack fashion, and allocations are not allowed>>
+ -- @ft<@i<from a subpool other than the one at the top of the stack. This is also>>
+ -- @ft<@i<the default pool.>>>
+
+@xcode< @b<subtype> Subpool_Handle @b<is> Subpools.Subpool_Handle;>
+
+@xcode< @b<type> Mark_Release_Pool_Type (Pool_Size : Storage_Count) @b<is new>
+ Subpools.Root_Storage_Pool_With_Subpools @b<with private>;>
+
+@xcode< @b<function> Mark (Pool : @b<in out> Mark_Release_Pool_Type)
+ @b<return not null> Subpool_Handle;>
+
+@xcode< @b<procedure> Release (Subpool : @b<in out> Subpool_Handle) @b<renames>
+ Ada.Unchecked_Deallocate_Subpool;>
+
+@xcode<@b<private>>
+
+@xcode< @b<type> MR_Subpool @b<is new> Subpools.Root_Subpool @b<with record>
+ Start : Storage_Count;
+ @b<end record>;
+ @b<subtype> Subpool_Indexes @b<is> Positive @b<range> 1 .. 10;
+ @b<type> Subpool_Array @b<is array> (Subpool_Indexes) @b<of aliased> MR_Subpool;>
+
+@xcode< @b<type> Mark_Release_Pool_Type (Pool_Size : Storage_Count) @b<is new>
+ Subpools.Root_Storage_Pool_With_Subpools @b<with record>
+ Storage : Storage_Array (1 .. Pool_Size);
+ Next_Allocation : Storage_Count := 1;
+ Markers : Subpool_Array;
+ Current_Pool : Subpool_Indexes := 1;
+ @b<end record>;>
+
+@xcode< @b<overriding>
+ @b<function> Create_Subpool (Pool : @b<aliased in out> Mark_Release_Pool_Type)
+ @b<return not null> Subpool_Handle;>
+
+@xcode< @b<function> Mark (Pool : @b<in out> Mark_Release_Pool_Type)
+ @b<return not null> Subpool_Handle @b<renames> Create_Subpool;>
+
+@xcode< @b<overriding>
+ @b<procedure> Allocate_From_Subpool (
+ Pool : @b<in out> Mark_Release_Pool_Type;
+ Storage_Address : @b<out> System.Address;
+ Size_In_Storage_Elements : @b<in> Storage_Count;
+ Alignment : @b<in> Storage_Count;
+ Subpool : @b<not null> Subpool_Handle);>
+
+@xcode< @b<overriding>
+ @b<procedure> Deallocate_Subpool (
+ Pool : @b<in out> Mark_Release_Pool_Type;
+ Subpool : @b<in out> Subpool_Handle);>
+
+@xcode< @b<overriding>
+ @b<function> Default_Subpool_for_Pool (
+ Pool : @b<in> Mark_Release_Pool_Type) return not null Subpool_Handle;>
+
+@xcode< @b<overriding>
+ @b<procedure> Initialize (Pool : @b<in out> Mark_Release_Pool_Type);>
+
+@xcode< -- @ft<@i<We don't need Finalize.>>>
+
+@xcode<@b<end> MR_Pool;>
+
+@xcode<@b<package body> MR_Pool @b<is>>
+
+@xcode< @b<procedure> Initialize (Pool : @b<in out> Mark_Release_Pool_Type) @b<is>
+ -- @ft<@i<Initialize the first default subpool.>>
+ @b<begin>
+ Pool.Markers(1).Start := 1;
+ Subpools.Set_Pool_of_Subpool
+ (Pool.Markers(1)'Unchecked_Access,
+ Pool'Unchecked_Access);
+ @b<end> Initialize;>
+
+@xcode< @b<function> Create_Subpool (Pool : @b<in out> Mark_Release_Pool_Type)
+ @b<return not null> Subpool_Handle @b<is>
+ -- @ft<@i<Mark the current allocation location.>>
+ @b<begin>
+ @b<if> Pool.Current_Pool = Subpool_Indexes'Last @b<then>
+ @b<raise> Storage_Error; -- @ft<@i<No more subpools.>>
+ @b<end if>;
+ Pool.Current_Pool := Pool.Current_Pool + 1; -- @ft<@i<Move to the next subpool>>>
+
+@xcode< @b<return> Result : @b<constant not null> Subpool_Handle :=
+ Pool.Markers(Pool.Current_Pool)'Unchecked_Access
+ @b<do>
+ Result.Start := Pool.Next_Allocation;
+ Subpools.Set_Pool_of_Subpool (Result, Pool'Unchecked_Access);
+ @b<end> return;
+ @b<end> Create_Subpool;>
+
+@xcode< @b<procedure> Deallocate_Subpool (
+ Pool : @b<in out> Mark_Release_Pool_Type;
+ Subpool : @b<in out> Subpool_Handle) @b<is>
+ @b<begin>
+ @b<if> Subpool /= Pool.Markers(Pool.Current_Pool)'Unchecked_Access @b<then>
+ @b<raise> Program_Error; -- @ft<@i<Only the last marked subpool can be released.>>
+ @b<end if>;
+ @b<if> Pool.Current_Pool /= 1 @b<then>
+ Pool.Next_Allocation := Pool.Markers(Pool.Current_Pool);
+ Pool.Current_Pool := Pool.Current_Pool - 1; -- @ft<@i<Move to the previous subpool>>
+ @b<else> -- @ft<@i<Reinitialize the default subpool:>>
+ Pool.Next_Allocation := 1;
+ Subpools.Set_Pool_of_Subpool
+ (Pool.Markers(1)'Unchecked_Access,
+ Pool'Unchecked_Access);
+ @b<end if>;
+ @b<end> Deallocate_Subpool;>
+
+@xcode< @b<function> Default_Subpool_for_Pool (
+ Pool : @b<in> Mark_Release_Pool_Type) @b<return not null> Subpool_Handle @b<is>
+ @b<begin>
+ @b<return> Pool.Markers(Pool.Current_Pool)'Unchecked_Access;
+ @b<end> Default_Subpool_for_Pool;>
+
+@xcode< @b<procedure> Allocate_From_Subpool (
+ Pool : @b<in out> Mark_Release_Pool_Type;
+ Storage_Address : @b<out> System.Address;
+ Size_In_Storage_Elements : @b<in> Storage_Count;
+ Alignment : @b<in> Storage_Count;
+ Subpool : @b<not null> Subpool_Handle) @b<is>
+ @b<begin>
+ @b<if> Subpool /= Pool.Markers(Pool.Current_Pool)'Unchecked_Access @b<then>
+ @b<raise> Program_Error; -- @ft<@i<Only the last marked subpool can be used for allocations.>>
+ @b<end if>;>
+
+@xcode< -- @ft<@i<Correct the alignment if necessary:>>
+ Pool.Next_Allocation := Pool.Next_Allocation +
+ ((-Pool.Next_Allocation) @b<mod> Alignment);
+ @b<if> Pool.Next_Allocation + Size_In_Storage_Elements @> Pool.Pool_Size @b<then>
+ @b<raise> Storage_Error; -- @ft<@i<Out of space.>>
+ @b<end if>;
+ Storage_Address := Pool.Storage (Pool.Next_Allocation)'Address;
+ Pool.Next_Allocation := Pool.Next_Allocation + Size_In_Storage_Elements;
+ @b<end> Allocate_From_Subpool;>
+
+@xcode<@b<end> MR_Pool;>
+
+
!ACATS test
Create ACATS C-Tests to test this facility.
@@ -1253,7 +1784,8 @@
Incidentally, I also found other uses for subpools and mark and release.
The pool I am interested in is intended to be very efficient. A precondition
guarantees that exactly one task can allocate from its subpool object abstraction.
-This eliminates the need to worry about concurrency, as each task gets its own subpool to work with, that are chained together and finalized with a top
+This eliminates the need to worry about concurrency, as each task gets its own subpool
+to work with, that are chained together and finalized with a top
level storage pool, resulting in fast allocations. Each task can deallocate its
subpool independently of the other tasks.
@@ -2329,7 +2861,8 @@
>> A dynamic_pool_name is expected to be the name of an object of any
>> descendant of
>> System.Storage_Pools.Dynamic_Pools.Dynamic_Storage_Pool, the type
->> representing dynamic storage pools defined in the language-defined package System.Storage_Pools.Dynamic_Pools (see 13.11.4).
+>> representing dynamic storage pools defined in the language-defined
+>> package System.Storage_Pools.Dynamic_Pools (see 13.11.4).
>>
>> Add after 7.6.1(20):
>>
@@ -2826,7 +3359,9 @@
Well, it's based specifically on Apache, so I'd probably include that in the
name.
-I did more-or-less the same thing in pure Ada, and I called it ... guess what? "Subpool". ;-) Tucker hi-jacked the term for AI-111, to mean something rather different, but it makes sense in his sense, too.
+I did more-or-less the same thing in pure Ada, and I called it ... guess what?
+"Subpool". ;-) Tucker hi-jacked the term for AI-111, to mean something rather
+different, but it makes sense in his sense, too.
>... I found then that the Ada time actually beat the C program by
>about 10% faster.
@@ -9064,5 +9599,273 @@
overridden.]
And delete the kludgy rule, as well as the AARM note explaining why it exists.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, May 2, 2011 9:44 PM
+
+[The appropriate part of a longer message - Editor]
+
+AI05-0111-3/10 Subpools, allocators, and control of finalization
+ [Bob has updated this AI twice to address various concerns with the previously approved
+ version. The largest change was to require that allocating a task from a subpool raises
+ Program_Error, as implementability of useful task termination semantics is unknown.]
+ Approve ____X__ Disapprove ______ Abstain _______
+ Comments: I believe it is confusing to talk about the subpool being null.
+ It makes more sense to talk about the subpool handle being null.
+ Hence, after 4.8(10.3/2):
+ If the allocator includes a *subpool_handle_*name, Constraint_Error is
+ raised if the subpool {handle} is null. Program_Error is raised if the
+ subpool does not *belong* (see 13.11.4) to the storage pool of the access
+ type of the allocator.
+
+ Where do we define what it means for a subpool to "belong" to a storage pool?
+ Is it just in the comments of "Set_Pool_Of_Subpool"? It might be nice to
+ pull this definition out into an introductory paragraph, and italicize it.
+ At the very least, it will need to be italicized in the comments defining
+ what Set_Pool_Of_Subpool does.
+
+ Do we anywhere explain what an implementor of a subpool is expected to do?
+ The Set_Pool_Of_Subpool and the Pool_Of_Subpool are non-abstract, while most
+ other operations in abstract. It would seem useful to put into a note or
+ AARM "redundant" brackets a sentence or two about how a subpool implementor
+ defines a subpool. We provide NOTEs in 13.11 explaining how a user can define
+ a "normal" storage pool. I think we should provide similar NOTEs in this section.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, May 2, 2011 10:30 PM
+
+[The appropriate part of a longer message - Editor]
+
+> AI05-0111-3/10 Subpools, allocators, and control of finalization
+> [Bob has updated this AI twice to address various concerns with the
+> previously approved version. The largest change was to require that
+> allocating a task from a subpool raises
+> Program_Error, as implementability of useful task termination
+> semantics is unknown.]
+> Approve ____X__ Disapprove ______ Abstain _______
+> Comments: I believe it is confusing to talk about the subpool being null.
+> It makes more sense to talk about the subpool handle being null.
+> Hence, after 4.8(10.3/2):
+> If the allocator includes a *subpool_handle_*name, Constraint_Error is
+> raised if the subpool {handle} is null. Program_Error is raised if the
+> subpool does not *belong* (see 13.11.4) to the storage pool of the
+> access type of the allocator.
+>
+> Where do we define what it means for a subpool to "belong" to a storage
+> pool? Is it just in the comments of "Set_Pool_Of_Subpool"? It might be
+> nice to pull this definition out into an introductory paragraph, and
+> italicize it.
+> At the very least, it will need to be italicized in the comments
+> defining what Set_Pool_Of_Subpool does.
+
+This AI is not formatted properly vis-a-vis the operation of the various
+routines -- the standard never puts semantics into comments (although I realize
+a lot of Ada programmers do). I figured I'd fix that when I made the final
+version of the AI (it's not significant to the technical content). That will
+pull the text into the body of the section, and then we just have to italicize
+the term (I certainly intend to do so, we'll see if I remember :-).
+
+> Do we anywhere explain what an implementor of a subpool is expected to do?
+> The Set_Pool_Of_Subpool and the Pool_Of_Subpool are non-abstract, while most
+> other operations in abstract. It would seem useful to put into a note or
+> AARM "redundant" brackets a sentence or two about how a subpool implementor
+> defines a subpool. We provide NOTEs in 13.11 explaining how a user can
+> define a "normal" storage pool. I think we should provide similar NOTEs
+> in this section.
+
+There is of course an extensive example of doing so in 13.11.6. NOTEs would be
+fine, but someone has to write them. Are you volunteering??
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, May 3, 2011 7:44 AM
+
+[The appropriate part of a longer message - Editor]
+
+>> We provide NOTEs in 13.11 explaining how a user can define
+>> a "normal" storage pool. I think we should provide similar NOTEs in
+>> this section.
+>
+> There is of course an extensive example of doing so in 13.11.6. NOTEs
+> would be fine, but someone has to write them. Are you volunteering??
+
+I would mostly just copy the notes from 13.11. And yes, I would be willing to
+give it a shot.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, May 3, 2011 5:33 PM
+
+[The appropriate part of a longer message - Editor]
+
+> I would mostly just copy the notes from 13.11. And yes, I would be
+> willing to give it a shot.
+
+I think you'd want to go just a bit further than that, to explain the use of
+Set_Pool_for_Subpool and the need to declare an extension of the subpool object
+(possibly in the body).
+
+Anyway, you've got yourself an assignment. Due ASAP, surely by the ballot
+closing date.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, May 3, 2011 6:51 PM
+
+> Anyway, you've got yourself an assignment. Due ASAP, surely by the
+> ballot closing date.
+
+Here you go.
+-Tuck
+--------
+
+ Comments on AI05-0111:
+
+ The following sentence isn't quite right:
+ If a subpool_specification is given, the storage pool of the access type
+ shall be a descendant of Root_Storage_Pool_with_Subpools.
+
+ It probably should say:
+ If a subpool_specification is given, the type of the storage pool of the
+ access type shall be a descendant of Root_Storage_Pool_with_Subpools.
+
+ Add the following user notes to explain typical usage:
+
+ NOTES:
+
+ + A user-defined storage pool type that supports subpools can be
+ implemented by extending the Root_Storage_Pool_With_Subpools
+ type, and overriding the primitive subprograms Create_Subpool,
+ Allocate_From_Subpool, and Deallocate_Subpool. Create_Subpool
+ should call Set_Pool_Of_Subpool before returning the subpool
+ handle. To make use of such a pool, a user would declare an
+ object of the type extension, use it to define the Storage_Pool
+ attribute of one or more access types, and then call
+ Create_Subpool to obtain subpool handles associated with the
+ pool.
+
+ + The pool implementor should override Default_Subpool_For_Pool if the pool is
+ to support a default subpool for the pool. The implementor can override
+ Deallocate if individual object reclamation is to be supported,
+ and can override Storage_Size if there is some limit on the
+ total size of the storage pool. The implementor can override
+ Initialize and Finalize if there is any need for non-trivial
+ initialization and finalization for the pool as a whole. For
+ example, Finalize might reclaim blocks of storage that are
+ allocated over and above the space occupied by the pool object
+ itself. The pool implementor may extend the Root_Subpool
+ type as necessary to carry additional information with each
+ subpool provided by Create_Subpool.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Monday, May 16, 2011 2:54 PM
+
+> I vote to approve all except
+>
+> 247 (Preconditions, Postconditions, multiple inheritance, and
+> dispatching calls)
+> and
+> 111 (subpools)
+>
+> I haven't made up my mind yet on those two.
+>
+
+I'll vote to approve those two also.
+
+For both, but especially subpools, it looks like there may be flaws that will
+need to be addressed later. Even so, it seems to me that there is enough value
+in getting something into Ada2012 to justify votes for approval. This is a close call
+and I can certainly understand and respect other people's opinions on this.
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Sunday, May 15, 2011 11:32 AM
+
+[The appropriate part of a longer message - Editor]
+
+AI05-0111-3/10 Subpools, allocators, and control of finalization
+ [Bob has updated this AI twice to address various concerns with the previously approved
+ version. The largest change was to require that allocating a task from a subpool raises
+ Program_Error, as implementability of useful task termination semantics is unknown.]
+ Approve ______ Disapprove ______ Abstain ___X___
+
+==================
+
+I do not like that deallocate_from_subpool is not supported, so that subpools
+are condemned to accumulate garbage. Ok for Mark/Release, but certainly not ok
+for other uses of subpools, e.g. to separate out equally sized heap blocks. I
+find this a serious limitation from my perspective, but I also see the
+implementation simplicity good for a Mark/release scheme. Not enough of an
+issue to disapprove the AI, but enough to not approve.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, May 17, 2011 1:43 AM
+
+For the record, subpools are *not* condemmed to accumulate garbage. The pool
+writer can implement Deallocate if they want, and clean up any garbage that way.
+This does require the pool writer to have some way to determine the appropriate
+subpool from the object address, but the alternatives are worse.
+
+If we had a Deallocate_from_Subpool operation, we would have to answer the
+question of where the subpool handle comes from. There are only two answers,
+both bad:
+ (1) The implementation is required to be able to figure out the subpool handle
+ to pass when Unchecked_Deallocation is called; this most likely means that
+ the implementation will have to "fatten" all access types that might have
+ subpools to include the subpool handle with the value. Among other things,
+ that means that subpools would incompatible with access values passed to
+ foreign languages. Ugh.
+ (2) Add a new version of Unchecked_Deallocation that took a subpool handle,
+ and the user would have to take the responsibility of conjoring it up and
+ passing it as a second parameter to Free. This is not very safe; if the
+ wrong handle is used, the results are likely to be a mess. Bob's opinion
+ that subpool management is generally safer than using
+ Unchecked_Deallocation would no longer be true. (The only half sane
+ argument in favor of this is that it is no worse than doing
+ Unchecked_Deallocation on a general access type value -- which at best is
+ arguing that since we got it so wrong once, we might as well do it again!)
+
+There is a third answer, which is to have the pool export a routine which takes
+an address and returns the correct subpool. (Tucker's original proposal had
+something like that.) But of course this just complicates the interface, since
+the pool writer can do that inside of Deallocate if they want to implement it,
+and there is no need to expose that operation.
+
+So the lack of this operation mainly comes from the fact that there is no safe
+way to define it. If there was one, we would have defined it.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, May 17, 2011 6:06 PM
+
+> For the record, subpools are *not* condemmed to accumulate garbage.
+> The pool writer can implement Deallocate if they want, and clean up
+> any garbage that way.
+
+Yes, this is one of the things that I'm pretty sure we got right about subpools.
+
+>...This does require the pool writer to have some way to determine the
+>appropriate subpool from the object address, ...
+
+Right. This can be done efficiently using a BiBOP approach, for example.
+
+As Randy explained, this should be the responsibility of the pool writer,
+because the Ada implementation can't do it efficiently, and because it's not
+always needed.
+
+...[Snipped more comments from Randy I agree with.]
****************************************************************
Questions? Ask the ACAA Technical Agent