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.
****************************************************************
Questions? Ask the ACAA Technical Agent