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

Differences between 1.1 and version 1.2
Log of other versions for file ai05s/ai05-0141-1.txt

--- ai05s/ai05-0141-1.txt	2009/02/14 07:27:08	1.1
+++ ai05s/ai05-0141-1.txt	2009/12/29 05:55:00	1.2
@@ -652,3 +652,130 @@
 though.
 
 ****************************************************************
+
+From: Steve Baird
+Date: Sunday, November 8, 2009  12:25 PM
+
+[Thoughts on this AI.]
+
+Don't forget about address_to_access_conversions.
+
+This may require a way of going "the other way", from a raw address back to a handle.
+
+We might also want to talk about Unchecked_Conversion between access types and System.Address,
+since this is a common idiom.
+
+****************************************************************
+
+The following was originally included in AI05-0139-2, but it
+doesn't have much to do with that AI and it has been removed. It
+has been saved here in case there is future desire to work on this AI (at this
+point, we believe that the facilities in AI05-0139-2 will make it possible
+to create useful persistent containers, so we don't think that this facility
+will be needed).
+
+USER DEFINED DEREFERENCE (AI05-141)
+
+The generic package Element_References might also be relevant to the
+notion of a user-defined "dereference" operation suggested in AI05-141. 
+One of the significant problems with AI05-141 as it stands is that there
+is no operation called when the dereference is "completed."  If we
+presume that the purpose of a user-defined dereference might be to
+implement some kind of software paging or persistence, then the page on
+which the designated object resides needs to be "pinned" in memory until
+the dereference is complete. But there is no user-defined cleanup
+routine provided in AI05-141. The Element_Reference and
+Element_Constant_Reference could provide for that, because they are
+derived from Limited_Controlled.
+
+So the suggestion is that, at least conceptually, there is an element
+reference object created, where the access discriminant comes from the
+result of the user-defined dereference, and when the resulting element
+reference object goes away, a user-defined cleanup routine would be
+called, perhaps to "unpin" the page on which the designated object
+resides.
+
+For practical reasons, rather than having the implementor of the storage
+pool provide extensions of Element_Reference and
+Element_Constant_Reference, they would instead just provide dereference
+operations similar to what is suggested in AI05-141, which takes in an
+"address" that might in fact not really be a machine address but rather
+an address-sized "locator" for the object that was returned by Allocate,
+and produces as a result a true machine address, suitable for use as the
+access discriminant of an element reference object.  There would be two
+of these operations, one for dereferencing an access-to-variable value,
+and one for dereferencing an access-to-constant value, and the work to
+be done might be quite different in the two cases (presuming, for
+instance, that the underlying storage pool is doing software paging). 
+In addition to the dereference operations, the implementor of the
+storage pool would provide two "cleanup" routines, which would be called
+when the hypothetical element reference object goes out of scope, again
+one for access-to-variable and one for access-to-constant.
+
+The import and export operations suggested in AI05-141 might still be
+provided for conversion to/from longer-lived access values.
+
+AI05-141 suggested that the dereference operation be accomplished
+through an IN-OUT parameter of type System.Address, allowing it to be
+the null procedure by default.  Given the number of operations we
+are now talking about, we would suggest defining a distinct
+("magic") descendant of Root_Storage_Pool that had these extra
+operations, two of which would more naturally be functions than procedures. The
+cleanup operations would ideally take three parameters, the storage
+pool, the original access value (which might not be a real machine
+address), and the "real" machine address produced by the dereference
+operation. Having both the original and the dereferenced value should
+simplify the cleanup operation.
+
+Here is a possible package System.Managed_Storage_Pools:
+
+    with System.Storage_Pools;
+    package System.Managed_Storage_Pools is
+        type Root_Managed_Storage_Pool is abstract new
+           Storage_Pools.Root_Storage_Pool with private;
+        
+        -- usual Allocate/Deallocate/Storage_Size routines,
+        -- inherited as abstract
+        
+        function Dereference(Pool : access Root_Managed_Storage_Pool; 
+          Access_Value : System.Address) return System.Address is abstract;
+          
+        function Constant_Dereference(Pool : access Root_Managed_Storage_Pool;
+          Access_Constant_Value : System.Address) return System.Address is abstract;
+          
+        procedure Cleanup_Dereference(Pool : access Root_Managed_Storage_Pool;
+          Access_Value : System.Address; Address_Value : System.Address) is null;
+          
+        procedure Cleanup_Constant_Dereference(Pool : access Root_Managed_Storage_Pool;
+          Access_Value : System.Address; Address_Value : System.Address) is null;
+          
+        function Export(Pool : access Root_Managed_Storage_Pool; 
+          Access_Value : System.Address) return System.Address is abstract;
+
+        function Import(Pool : access Root_Managed_Storage_Pool;
+          Address_Value : System.Address) return System.Address is abstract;
+          
+    private
+        -- not specified
+    end System.Managed_Storage_Pools;
+    
+Note that the use of element references is completely behind the scenes with
+this approach.  These access values work just like "regular" access values,
+but behind the scenes:
+
+  * on each dereference or conversion to an access parameter or
+    access discriminant they get temporarily made available as "true"
+    addresses via the user-defined dereference routines, and then get 
+    cleaned up.
+    
+  * on conversion to an access type that is not for an access parameter
+    or access discriminant, if the storage pool of the new access type
+    is different, they get permanently converted into a "normal"
+    address value via the Export function (which might raise PROGRAM_ERROR).
+    
+  * on conversion from an access type of a different storage pool, the
+    new access values are produced by calling the Import function, which might
+    raise PROGRAM_ERROR if importing from another storage pool is not
+    supported.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent