CVS difference for ai05s/ai05-0224-1.txt
--- ai05s/ai05-0224-1.txt 2011/01/29 01:03:25 1.7
+++ ai05s/ai05-0224-1.txt 2011/02/16 06:15:23 1.8
@@ -354,6 +354,363 @@
****************************************************************
From: Steve Baird
+Sent: Friday, November 19, 2010 6:10 PM
+
+Here are some missing pieces for this AI (it currently only has !question and
+!appendix sections).
+
+ -- Steve
+
+====
+
+
+!subject No_Task_Allocators and classwide returns
+
+----
+
+!summary
+No_Task_Allocators restriction also implies a runtime check.
+
+----
+
+!question (append to end of existing !question section):
+
+(task allocation is detected at runtime and Program_Error is raised).
+
+----
+
+!wording
+
+Append to the end of D.7(7):
+
+ This rule is enforced via a post-compilation check.
+
+ In addition, a (runtime) check is performed as part of
+ the evaluation of any allocator of a type having a
+ class-wide limited designated type; a check is made
+ that the specific type of the allocated object has no task
+ subcomponents. Program_Error is raised if this check fails.
+ This check is performed before any task subcomponents of
+ of the function result object are activated.
+
+ A runtime check may be needed in the case of an allocated
+ object which is initialized by a function call with a
+ limited class-wide result type. In this case, the check may
+ be performed at the point of the return statement within the
+ function with Program_Error being raised at the point of the call
+ in much the same way that constraint checks may be performed "early"
+ as described in section 6.5's "Implementation Permissions".
+
+----
+
+!discussion
+
+This AI does not address the general question of how restriction pragmas
+interact with conditional expressions.
+
+If it is determined that something like
+
+ type Root is tagged limited null record;
+ type Ref is access Root'Class;
+
+ type Has_Tasks is new Root with Tsk : Some_Task_Type; end record;
+
+
+ Ptr : Ref := new Root'Class'(if Flag then Root'(...)
+ else Has_Tasks'(...));
+
+makes it past the post-compilation check (assuming that a No_Task_Allocators
+restriction is given), then the runtime check here will fail if Flag turns out
+to be False.
+
+===
+
+Is it ok that all of the wording changes for this AI go into the "static
+semantics" section, even though we are discussing dynamic semantics and
+implementation permissions? The description of each restriction in this section
+is contiguous and it would be awkward to break this one up.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, November 19, 2010 9:42 PM
+
+...
+> In addition, a (runtime) check is performed as part of
+> the evaluation of any allocator of a type having a
+> class-wide limited designated type; a check is made
+> that the specific type of the allocated object has no task
+> subcomponents. Program_Error is raised if this check fails.
+> This check is performed before any task subcomponents of
+> of the function result object are activated.
+>
+> A runtime check may be needed in the case of an allocated
+> object which is initialized by a function call with a
+> limited class-wide result type. In this case, the check may
+> be performed at the point of the return statement within the
+> function with Program_Error being raised at the point of the call
+> in much the same way that constraint checks may be performed "early"
+> as described in section 6.5's "Implementation Permissions".
+
+This runtime check seems to have way too much description; it's bordering on
+verbal diarrhea. No one cares where this check happens, just that it does rather
+than performing an action that violates the restriction. We decided during the
+call that we don't care if such a program leaks memory -- it's buggy!
+
+Moreover, Max_Tasks merely says "If an implementation chooses to detect a
+violation of this restriction, Storage_Error should be raised."
+
+For this one, detection is not optional, but similar wording can be used:
+
+"If an implementation detects a violation of this restriction other than those
+detected by the Post-compilation checks, Program_Error should be raised."
+
+AARM Discussion: A runtime check is needed as part of the evaluation of any
+allocator of a type having a class-wide limited designated type in case the
+actual specific type has a task component. We do not say specifically where the
+check is made or the exception raised, but in no case should a task be allocated
+before the exception is raised."
+
+That seems like enough, and maybe this can be simplified even further.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Monday, November 22, 2010 4:24 PM
+
+> For this one, detection is not optional, but similar wording can be used:
+>
+> "If an implementation detects a violation of this restriction other
+> than those detected by the Post-compilation checks, Program_Error
+> should be raised."
+
+This wording is not appropriate because detection is not optional.
+For required detection, I think you need to say "a check is performed"
+in there somewhere.
+
+> AARM Discussion: A runtime check is needed as part of the evaluation
+> of any allocator of a type having a class-wide limited designated type
+> in case the actual specific type has a task component. We do not say
+> specifically where the check is made or the exception raised, but in
+> no case should a task be allocated before the exception is raised."
+
+I don't think like the idea of using wording appropriate for an optional check
+in the RM and then trying to tighten things up with an AARM note.
+
+Incidentally, requiring that a task must not be "allocated" (as you suggested)
+is a tighter requirement than requiring that it must not be "activated" (as I
+suggested). In the case of a build-in-place function used to initialize an
+allocator, it sounds like you are requiring that the check must be performed at
+the point of the return statement, not at the call site. Do you agree, and did
+you intend this?
+
+I certainly want to allow this behavior, but I'm less sure about requiring it.
+Requiring it does, however, eliminate the need for the second of the two
+paragraphs that I proposed. We don't need an implementation permission to allow
+something that is required. So maybe "allocated" is better than "activated" in
+this case.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, November 22, 2010 4:57 PM
+
+> > "If an implementation detects a violation of this restriction other
+> > than those detected by the Post-compilation checks, Program_Error
+> > should be raised."
+>
+> This wording is not appropriate because detection is not optional.
+> For required detection, I think you need to say "a check is performed"
+> in there somewhere.
+
+The wording "a check" has a specific semantic meaning in Ada, and I don't
+believe that a restriction can ever cause "a check". Moreover, a check has to
+occur at a particular place during the execution of the code, and this is
+precisely what we do not want to require of restrictions.
+
+So I don't think the wording "a check" is ever appropriate here. Note that there
+is no existing restriction which ever uses the wording "a check"; it would be
+bizarre for this one to be the first.
+
+> > AARM Discussion: A runtime check is needed as part of the evaluation
+> > of any allocator of a type having a class-wide limited designated
+> > type in case the actual specific type has a task component. We do
+> > not say specifically where the check is made or the exception
+> > raised, but in no case should a task be allocated before the exception is raised."
+>
+> I don't think like the idea of using wording appropriate for an
+> optional check in the RM and then trying to tighten things up with an
+> AARM note.
+
+I wasn't trying to "tighten things up", just explain what appears to be
+necessary and a possible implementation. And I didn't want to use the wording "a
+check" here, either, but couldn't find another English word which didn't obscure
+the meaning too much. I probably ought to have put "probably" before "is needed"
+to make it clear that another implementation is fine.
+
+> Incidentally, requiring that a task must not be "allocated" (as you
+> suggested) is a tighter requirement than requiring that it must not be
+> "activated" (as I suggested).
+> In the case of a build-in-place function used to initialize an
+> allocator, it sounds like you are requiring that the check must be
+> performed at the point of the return statement, not at the call site.
+> Do you agree, and did you intend this?
+
+The restriction is "No_Task_Allocators" not
+"No_Tasks_Activated_as_part_of_Allocators". It doesn't make sense to talk about
+task activation here. (But I admit I did not notice you were talking about
+activation, other than in general you appeared to over-specify the semantics.)
+
+> I certainly want to allow this behavior, but I'm less sure about
+> requiring it. Requiring it does, however, eliminate the need for the
+> second of the two paragraphs that I proposed. We don't need an
+> implementation permission to allow something that is required.
+> So maybe "allocated" is better than "activated" in this case.
+
+I don't see that the wording I gave requires any such thing. We decided that we
+don't care about memory leakage here, so there is no problem with allocation. If
+my wording does require that (or anything else for that matter), it is wrong.
+
+Depending on the task runtime system, it might very well require that no
+allocations be done (because there is no code in the RTS to do such
+allocations). But other runtimes might not care, if the mechanism to create a
+task is the same for allocators and stack-based objects.
+
+I still think you are trying way too hard to over-specify this restriction. I
+want the wording to be a vague as possible, since we really don't care when or
+where the violation is detected. (I think it would be OK for an allocated task
+to start running, so long as the partition never completes normally. Or [more
+likely] it would be OK for the exception to be raised as soon as the partition
+starts running, if a post-compilation check has determined that the violation
+will happen.)
+
+Runtime restrictions are overall things vaguely defined, simply because a
+program that violates a restriction is seriously flawed, and we don't care what
+they do beyond raising the exception, sometime, somewhere. That goes for *all*
+restrictions, not just this one.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Monday, November 22, 2010 5:48 PM
+
+> The wording "a check" has a specific semantic meaning in Ada, and I
+> don't believe that a restriction can ever cause "a check".
+
+13.12 says
+ A restriction may impose requirements on the runtime behavior of the
+ program, as indicated by the specification of runtime behavior
+ associated with a violation of the requirement.
+
+To me, this clearly means that restriction theoretically could cause a check.
+I'm not claiming that this is terribly important.
+
+> So I don't think the wording "a check" is ever appropriate here. Note
+> that there is no existing restriction which ever uses the wording "a
+> check"; it would be bizarre for this one to be the first.
+
+What's unique about this restriction is that we seem to have (perhaps
+inadvertently) broken new ground by adding the rule that runtime checks to
+detect violations of this restriction are required. Is there any other
+restriction for which this is the case? I think not. Perhaps we should revisit
+this decision. We did not discuss the fact that required runtime enforcement of
+a restriction is something new.
+
+If we only require optional enforcement, then I agree with what you have said
+about this AI.
+
+Whatever we decide to do probably needs to be duplicated for
+No_Proteted_Type_Allocators.
+
+****************************************************************
+
+From: Alan Burns
+Sent: Tuesday, November 23, 2010 2:11 AM
+
+Under Ravenscar there is a requirement (expressed as a restriction I think) that
+Program_Error should be raised if there is a suspension/delay inside a protected
+object. Without this restriction the situation is a bounded error with 'ignore'
+being one of the options. So is this not an example of a restriction requiring a
+run-time check?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, November 23, 2010 12:33 PM
+
+You're thinking of pragma Detect_Blocking (H.5), which is not expressed in the
+form of a restriction. (And it doesn't use the term "check", either.)
+
+Steve said:
+> What's unique about this restriction is that we seem to have (perhaps
+> inadvertently) broken new
+> ground by adding the rule that runtime checks to detect violations of
+> this restriction are required.
+> Is there any other restriction for which this is the case? I think not.
+> Perhaps we should revisit this decision. We did not discuss the fact
+> that required runtime enforcement
+> of a restriction is something new.
+>
+> If we only require optional enforcement, then I agree with what you
+> have said about this AI.
+
+The problem with that is that this restriction is used in Ravenscar.
+However, I don't think that is relevant, because Ravenscar also contains
+No_Task_Hierarchy, which means that a function can never return a task. Thus the
+situation that causes the problem will never arise.
+
+> Whatever we decide to do probably needs to be duplicated for
+No_Proteted_Type_Allocators.
+
+That's actually a different case, because there is nothing in Ravenscar
+preventing these from being returned from functions. I don't know if that is a
+hole in Ravenscar (seems possible) or whether it is intended to allow functions
+to initialize library-level protected objects. I suppose one could argue that
+No_Local_Protected_Objects disallows a function from returning a protected
+object, as the return object would momentarily be considered local; but given
+that these are build-in-place objects its surely not as clear-cut.
+
+Alan, is the intent that Ravenscar disallow protected objects returned from
+functions? Or did no one ever think about it??
+
+****************************************************************
+
+From: Steve Baird
+Sent: Tuesday, November 23, 2010 12:49 PM
+
+> I suppose one could
+> argue that No_Local_Protected_Objects disallows a function from
+> returning a protected object, as the return object would momentarily
+> be considered local; ...
+
+One could and I would.
+
+"Momentarily" is a somewhat misleading word in the context of an extended return
+statement.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, November 23, 2010 1:19 PM
+
+True, but we also have to consider a simple return of an aggregate. In that case
+(since there is no temporary), a local object is invisible.
+
+****************************************************************
+
+From: Alan Burns
+Sent: Wednesday, November 24, 2010 3:24 AM
+
+Really we did not think about it - we were more concerned about threads
+- are there any issues
+that would want us to disallow from Ravenscar? I guess silly code could create
+an arbitrary number of objects, but that seems more an issue for dynamic
+creation of objects anyway and might be part of the restrictions for the
+sequential part of any complete language subset.
+
+****************************************************************
+
+From: Steve Baird
Sent: Friday, January 28, 2011 3:10 PM
Based on yesterday's phone meeting, I now suggest that the !wording section of
@@ -376,8 +733,8 @@
has no protected subcomponents. Program_Error is raised if
this check fails.
-Please ignore the subsequent wording changes that were previously proposed, beginning
-with
+Please ignore the subsequent wording changes that were previously proposed,
+beginning with
Add after D.7(19.1/2)
Questions? Ask the ACAA Technical Agent