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

--- ai05s/ai05-0224-1.txt	2010/10/21 06:25:03	1.1
+++ ai05s/ai05-0224-1.txt	2010/10/26 05:33:36	1.2
@@ -161,3 +161,169 @@
 think we'll need some additional wording for this rule (whatever we decide).
 
 ****************************************************************
+
+From: Steve Baird
+Sent: Thursday, October 21, 2010  4:47 PM
+
+Before trying to come up with wording for this recently-created AI, I need to
+know what rule we want to express.
+
+!question
+
+How does the No_Task_Allocators restriction interact with a function that
+returns Some_Limited_Type'Class, as in
+
+     type Ref is access Some_Limited_Type'Class;
+
+     type T is new Some_Limited_Type with
+       record Tsk : Some_Task_Type; end record;
+
+     function F return Some_Limited_Type'Class is
+     begin return X : T; end F;
+
+     Ptr : Ref := new Some_Limited_Type'Class'(F);
+
+Possible solutions include:
+
+    1) If the restriction is given, then conservatively
+       reject all access-to-limited-classwide
+       allocators on the grounds that they
+       might violate the restriction.
+
+    2) A post-compilation check that
+       if the restriction is given and an
+       allocator exists which allocates an object of type
+       Some_Limited_Type'Class, then there exist
+       no extensions of Some_Limited_Type which
+       have task subcomponents. Or something like that.
+
+    3) A runtime check that raises Program_Error if the
+       restriction is in force and the program
+       attempts to allocate a task (via some mechanism
+       such as the given example which makes it past the
+       static checks).
+
+
+I'd like to get a consensus on what we want here so that I can try to have
+wording for it before the Fairfax meeting.
+
+Opinions?
+
+P.S. My preference order is #2, #1, #3.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, October 21, 2010  5:13 PM
+
+> Before trying to come up with wording for this recently-created AI,
+
+It seems to be so recent that it's in the future.
+That is, I don't see it on the ada-auth web site.
+And I've never heard of it.
+
+So I'm kind of flying blind here, but...
+
+> P.S. My preference order is #2, #1, #3.
+
+Hmm.  I think #3 is best.
+
+#1 is no good -- why should limited types be punished just because they MIGHT
+contain tasks?
+
+#2 is a big pain for implementers, for little gain.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Thursday, October 21, 2010  5:25 PM
+
+>> Before trying to come up with wording for this recently-created AI,
+>
+> It seems to be so recent that it's in the future.
+> That is, I don't see it on the ada-auth web site.
+> And I've never heard of it.
+>
+
+Yeah, this one just landed in my lap today, but if you've seen the !question section, then you've seen the whole AI at this point.
+
+> So I'm kind of flying blind here, but...
+>
+>> P.S. My preference order is #2, #1, #3.
+>
+> Hmm.  I think #3 is best.
+
+Thanks for taking the time to reply.
+
+I don't feel strongly about it, but my idea was that implementors of a runtime
+system which is built for use with this restriction don't want to deal with this
+issue at all. They want to know statically that task allocation can't happen.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, October 21, 2010  5:40 PM
+
+> Thanks for taking the time to reply.
+
+You're welcome.
+
+> I don't feel strongly about it, but my idea was that implementors of a
+> runtime system which is built for use with this restriction don't want
+> to deal with this issue at all. They want to know statically that task
+> allocation can't happen.
+
+Yes, I agree with that.  But replacing every "create some tasks"
+with "raise.." seems easy, and accomplishes that goal, while all kinds of
+link-time checks seems hard.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, October 21, 2010  5:58 PM
+
+...
+> > Before trying to come up with wording for this recently-created AI,
+>
+> It seems to be so recent that it's in the future.
+> That is, I don't see it on the ada-auth web site.
+> And I've never heard of it.
+
+It was created out of mail from this list on June 7th. So you *ought* to have
+heard of it (but you didn't comment on it at the time).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, October 21, 2010  6:06 PM
+
+...
+> > I don't feel strongly about it, but my idea was that implementors of
+> > a runtime system which is built for use with this restriction don't
+> > want to deal with this issue at all. They want to know statically
+> > that task allocation can't happen.
+>
+> Yes, I agree with that.  But replacing every "create some tasks"
+> with "raise.." seems easy, and accomplishes that goal, while all kinds
+> of link-time checks seems hard.
+
+Humm. I guess I don't see this, as it seems unlikely to me that the check could
+be performed outside of the task supervisor. So quite a bit of the overhead of
+creating tasks would be present in the generated code, even if it wasn't used.
+That's not the point.
+
+Specifically, I don't see how the function F in Steve's example could be
+compiled without the overhead of being able to create tasks, because there is no
+way for it to know whether it is called from an allocator (which would raise an
+exception) or from an object initialization (which would work - at least in the
+absence of other restrictions). And that means that the call site would need at
+least some of the overhead of task creation in order to be able to meet the
+calling convention of the function (since it couldn't know if a task was
+actually created, and no exception could be raised if it was not).
+
+Indeed, that seems to be a problem for *any* version of this restriction other
+than the over-the-top #1.
+
+Not sure what to do here...
+
+****************************************************************