CVS difference for ai05s/ai05-0111-1.txt

Differences between 1.12 and version 1.13
Log of other versions for file ai05s/ai05-0111-1.txt

--- ai05s/ai05-0111-1.txt	2010/02/23 22:43:18	1.12
+++ ai05s/ai05-0111-1.txt	2010/02/25 05:01:42	1.13
@@ -290,13 +290,13 @@
 
   end System.Subpools;
 
-A *subpool* is a storage pool whose type is descended from Root_Subpool.
-The Manager discriminant of a subpool designates its *subpool manager*,
-which is a storage pool whose type is descended from
-Root_Subpool_Manager. When an allocator with a subpool_specification
-is evaluated, a call is made on Allocate_From_Subpool passing in the
-given Subpool_Handle, in addition to the parameters as defined
-for calls on Allocate (see 13.11).
+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, called the *subpool manager*, which is a
+storage pool whose type is descended from Root_Subpool_Manager. When an
+allocator with a subpool_specification is evaluated, a call is made on
+Allocate_From_Subpool passing in the given Subpool_Handle, in addition to the
+parameters as defined for calls on Allocate (see 13.11).
 
 When a task creates an object of the type Default_Subpool_Specifier by
 calling Establish_Default_Subpool, the specified Subpool becomes the
@@ -425,7 +425,7 @@
 
 In an assignment operation, if the target is a variable of an access type whose
 storage pool is a subpool manager, and the value being assigned is non-null,
-then a check is made that the object designed by the value being assigned was
+then a check is made that the object designated by the value being assigned was
 allocated from a subpool that is reachable from the master of the target object.
 An attribute is provided to check reachability before performing an assignment:
 
@@ -5258,5 +5258,87 @@
 can write the rest in regular Ada (although you might have to depend on runtime
 checks in some cases). Thus I don't see much reason for it to be in the
 standard, absent demand. We'll discuss this further this weekend.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, February 23, 2010  5:28 PM
+
+> I've fixed that and the abstract
+
+Thanks.  I also discovered that the first couple of sentences immediately
+following the spec for the System.Subpools package were left over from an
+earlier version.  So please replace:
+
+   A *subpool* is a storage pool whose type is
+   descended from Root_Subpool. The Manager discriminant
+   of a subpool designates its *subpool manager*,
+   which is a storage pool whose type is descended from
+   Root_Subpool_Manager. ...
+
+with:
+
+   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, called the *subpool manager*, which is
+   a storage pool whose type is descended from
+   Root_Subpool_Manager.  ...
+
+I also wrote "designed" rather than "designated" at least once.
+
+>> I eliminated the Annex H stuff, because Steve convinced me that
+>> dumping the dangling-reference prevention in there didn't make sense.
+>
+> Well, I disagree; this version seems to have reintroduced all of the
+> junk that I find distasteful. As I've said previously, the one thing
+> that you can't write yourself is the early finalization of objects in
+> a subpool. I believe that you can write the rest in regular Ada
+> (although you might have to depend on runtime checks in some cases).
+> Thus I don't see much reason for it to be in the standard, absent
+> demand. We'll discuss this further this weekend.
+
+I believe there is definitely demand for some kind of safe mark/release storage
+management.  I believe it is important to be able to use an allocator to create
+the objects, because it is important to get all the various object
+initialization alternatives provided by allocators. I looked into doing
+initialization with some amazing generic, but it was just too difficult to
+provide the equivalent flexibility of the uninitialized and initialized
+allocators.  So once you are using allocators, then you are also using access
+types, and we end up needing some kind of check on access value assignment to
+avoid creating dangling references.
+
+If we choose to avoid using access values, and only use something like cursors
+to designate objects, then we might be able to write this all in "regular Ada,"
+but I'm not convinced it would be any easier to understand or use, nor that much
+less work to implement.  I believe that the packages I have specified can be
+implemented in "regular" Ada.  The only compiler "magic" has to do with the
+'Reachable attribute function.  And from a standardization point of view, we
+know it is a lot of work to define a new container type, so if we are going to
+do all that work, it seems a feature to be able to use "regular" access types.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, February 23, 2010  5:50 PM
+
+I think trying to fix up access types is just putting lipstick on a pig. Access
+types are inherently unsafe, and they are going to stay that way despite all
+efforts. The important thing is to be able to build safe abstractions on top of
+them.
+
+The only comment that I saw in your Parasail blog was one questioning this very
+thing: why are you creating something so hard to use when "everyone" uses
+garbage collection? Obviously, we don't think garbage collection is a good idea
+for avionics software ("please wait" is not something pilots should be seeing
+from their cockpit software!). But offering a complex structure that no one
+understands (OK, no one other than Tuck) isn't helping. And garbage collection
+is still impossible even when appropriate. I think this is more likely to make
+us a laughingstock than visionaries (even if we are right).
+
+Anyway, we both ought to be doing our important homework for the meeting, and
+discussing this isn't helping. Talk to you Friday (weather and airlines
+permitting).
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent