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

--- ai05s/ai05-0189-1.txt	2010/06/11 04:53:38	1.4
+++ ai05s/ai05-0189-1.txt	2010/11/13 03:31:35	1.5
@@ -1,16 +1,24 @@
-!standard D.7 (19.1/2)                                10-06-07  AI05-0189-1/02
+!standard D.7 (19.1/2)                                10-10-30  AI05-0189-1/03
 !standard H.4(23.3/2)
+!standard C.7.1(3/1)
+!standard C.7.1(4)
+!standard C.7.1(8)
+!standard C.7.1(10)
 !class amendment 09-11-03
 !status work item 09-11-03
 !status received 09-11-03
 !priority Low
 !difficulty Easy
-!subject Restriction No_Allocators_After_Elaboration
+!subject Restriction No_Default_Storage_Pools_After_Elaboration
 
 !summary
 
-Provide a restriction that disallows use of allocators after
-library unit elaboration is complete.
+Provide a restriction that disallows use of allocators from default
+storage pools after library unit elaboration is complete. Also provide
+additional operations in Task_Identification to permit identifying the
+environment task, and whether a task has completed its activation,
+to enable user-defined storage managers to enforce a corresponding
+restriction.
 
 !problem
 
@@ -25,36 +33,63 @@
 
 !wording
 
+Modify C.7.1(3/1):
+
+    function Current_Task return Task_Id;
+{   function Environment_Task return Task_Id;}
+    procedure Abort_Task(T : in Task_Id);
+
+Add after C.7.1(4):
+
+    function Activation_Is_Completed(T : Task_Id) return Boolean;
+
+Add after C.7.1(8):
+
+    The function Environment_Task returns a value that identifies the
+    environment task.
+
+Add after C.7.1(10):
+
+    The function Activation_Is_Complete returns True if the task
+    identified by T has completed its activation (whether successfully
+    or not). It returns False otherwise.  If T identifies the
+    environment task, Activation_Is_Complete returns True after the
+    elaboration of the library_items of the partition has completed.
+
 Add after D.7(19.1/2):
 
-  No_Allocators_After_Elaboration
+  No_Default_Storage_Pools_After_Elaboration
 
-     Specifies that the only allocators that may be evaluated during the
-     execution of the partition are during the elaboration of the library_items
-     of the partition, prior to the invocation of any main subprogram. An
-     allocator shall not occur after the begin of a task body nor in the main
-     subprogram. If an implementation chooses to detect a violation of
-     this restriction at run-time, Storage_Error should be raised;
-     otherwise the behavior is implementation defined.
+     Specifies that an allocator using a default storage pool raises
+     Storage_Error if it is evaluated at any time after the elaboration
+     of the library_items of the partition has completed.  In addition,
+     an allocator using a default storage pool shall not occur within a
+     parameterless library subprogram, nor within a task body after the
+     begin of the body.  Within a generic body, an allocator of a type
+     derived from a formal access type is permitted.
 
 Revise H.4(23.3/2) as follows:
 
   * the following restrictions defined in D.7: No_Task_Hierarchy,
     No_Abort_Statement, No_Implicit_Heap_Allocation
-    {, No_Allocators_After_Elaboration}; and
+    {, No_Default_Storage_Pools_After_Elaboration}; and
 
 !discussion
 
-We considered restricting allocators to the environment
-task, but felt it was important to allow non-environment
-tasks to perform allocators during their activation. Note
-that allowing non-environment tasks to perform allocators
-means that synchronization is still required during heap
-allocation.
+We considered restricting allocators to the environment task, but felt
+it was important to allow non-environment tasks to perform allocators
+during their activation. Note that allowing non-environment tasks to
+perform allocators means that synchronization is still required during
+heap allocation.
 
 We do not require this restriction to be entirely enforced prior to
-execution. We perhaps could do so, but to do it completely
-could require significant static analysis.
+execution. We perhaps could do so, but to do it completely could require
+significant static analysis.
+
+The original proposal disallowed all allocators after elaboration, but
+it seemed preferable to allow user-defined storage pool implementations
+to enforce the restriction themselves by providing enough information
+via additional Task_Identification queries.
 
 !examples
 
@@ -224,5 +259,26 @@
 As I told Steve, this is merely a question of consistency with other
 restrictions. Exactly how restrictions are enforced has pretty much always been
 to some degree implementation defined.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Saturday, October 30, 2010  9:43 PM
+
+Here is an update to the No_Allocators_After_Elaboration restriction AI.
+[This is version /03 of the AI - Editor.] At the last ARG meeting, we had
+decided to limit this restriction to allocators using a default storage pool,
+and add some queries in Task_Identification to enable user-defined storage pool
+implementations to enforce the restriction themselves. To correspond to the
+change in semantics of the restriction, we have changed the name of the
+restriction to No_Default_Storage_Pools_After_Elaboration.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, October 30, 2010 11:15 PM
+
+Silly bug: the function is defined as Activation_Is_Completed, but the text
+identifies Activation_Is_Complete.
 
 ****************************************************************