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

Differences between 1.3 and version 1.4
Log of other versions for file ai05s/ai05-0189-1.txt

--- ai05s/ai05-0189-1.txt	2010/01/09 01:31:30	1.3
+++ ai05s/ai05-0189-1.txt	2010/06/11 04:53:38	1.4
@@ -1,4 +1,5 @@
-!standard D.7 (19.1/2)                                09-11-03  AI05-0189-1/01
+!standard D.7 (19.1/2)                                10-06-07  AI05-0189-1/02
+!standard H.4(23.3/2)
 !class amendment 09-11-03
 !status work item 09-11-03
 !status received 09-11-03
@@ -27,25 +28,32 @@
 Add after D.7(19.1/2):
 
   No_Allocators_After_Elaboration
-  
+
      Specifies that the only allocators that may be evaluated during the
-     execution of the partition are within the execution of the
-     environment task, during the elaboration of the library_items of
-     the partition, prior to the invocation of any main subprogram. An
-     allocator shall not occur within a task body or the main
+     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.
-     
+
+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
+
 !discussion
 
-For simplicity, we have restricted allocators to the environment task, 
-even though it might be possible for a non-environment task to execute 
-entirely during library-item elaboration. This also eliminates the need
-for synchronization 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 
+execution. We perhaps could do so, but to do it completely
 could require significant static analysis.
 
 !examples
@@ -101,5 +109,120 @@
 the compiler by removing pragma Restrictions to permit the elaboration code
 to use dynamic memory allocation, but in that manner we lose the ability to
 enforce the restriction for the code executed after elaboration.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, June 7, 2010  10:53 AM
+
+Here is a minor update to the AI on the
+restriction No_Allocators_After_Elaboration. [This is version /02 of the AI - Editor.]
+Note that the minutes implied that library-level tasks weren't certain to be
+activated until the "begin" of the main subprogram.  Actually, they must be
+activated before the main subprogram is invoked at all. (See 10.2(20-21) which
+indicates that the call on the main subprogram follows the "begin" of the
+conceptual environment task body.)
+
+****************************************************************
+
+From: Steve Baird
+Sent: Monday, June 7, 2010  1:32 PM
+
+> An allocator shall not occur after the begin of a task body nor in the main subprogram.
+
+This is fundamentally a rule about a runtime check and the (not particularly
+common) statically detectable cases listed above don't seem to me to be worth
+special treatment.
+
+> If an implementation chooses to detect a violation of this restriction
+> at run-time, Storage_Error should be raised;
+
+Why is this optional? Do you think that the performance advantage of this
+approach outweighs the portability costs?
+
+****************************************************************
+
+From: Steve Baird
+Sent: Monday, June 7, 2010  1:47 PM
+
+> Why is this optional? Do you think that the performance advantage of
+> this approach outweighs the portability costs?
+
+It's a significant overhead to require the testing of a global variable on every
+single allocation, so it seems reasonable not to require it. I suppose we could
+associate a check name with it, so that the check could be specifically
+suppressed?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, June 7, 2010  1:52 PM
+
+>> An allocator shall not occur after the begin of a task body nor in
+>> the main subprogram.
+>
+> This is fundamentally a rule about a runtime check and the (not
+> particularly common) statically detectable cases listed above don't
+> seem to me to be worth special treatment.
+
+The straw vote was 5-3-3 to keep a static check on task bodies.  So that's why
+it is there.
+
+>> If an implementation chooses to detect a violation of this
+>> restriction at run-time, Storage_Error should be raised;
+>
+> Why is this optional? Do you think that the performance advantage of
+> this approach outweighs the portability costs?
+
+This is the standard way that restrictions are worded.
+See, e.g., D.7(20) on Max_Storage_At_Blocking.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Monday, June 7, 2010  2:05 PM
+
+> The straw vote was 5-3-3 to keep a static check on task bodies.  So
+> that's why it is there.
+>
+
+Fine.
+
+> This is the standard way that restrictions are worded.
+> See, e.g., D.7(20) on Max_Storage_At_Blocking.
+
+That's a bad example because the meaning of what is being checked there is very
+implementation dependent.
+
+Since Max_Asynchronous_Select_Nesting has the same sort of wording, however, I
+do see your point.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Monday, June 7, 2010  2:42 PM
+
+>> Why is this optional? Do you think that the performance advantage of
+>> this approach outweighs the portability costs?
+>
+> It's a significant overhead to require the testing of a global
+> variable on every single allocation, so it seems reasonable not to
+> require it. I suppose we could associate a check name with it, so that
+> the check could be specifically suppressed?
+
+What good is there in putting a restriction if it not checked neither at
+compile-time nor at run-time?
+
+I'd rather require a run-time check, and allow the compiler to reject the
+restriction if it is not supported.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, June 7, 2010  2:54 PM
+
+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.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent