Re: Interresting difference in Normal-Returns/Expression-Functions and Extended-Returns.

[Adam Beneschan <adam@irvine.com>]

On Monday, April 22, 2013 11:27:09 AM UTC-7, Shark8 wrote:
> I recently ran into unexpected behavior in the differences between a normal return and an extended return [in GNAT]: namely an extended return used to generate items in an array of tasks will *ALWAYS* execute in a sequential manner whereas the array generated with an expression-function or normal return is executed simultaneously.
> 
> Is there some subtle difference in the extended return that I'm unaware of? (Is this a bug?)

OK, I think I've figured it out--egilhh was on the right track.  The
key rules are 7.6.1(4), "For the finalization of a master, dependent
tasks are first awaited, as explained in 9.3", and 9.3(2):

"If the task is created by the evaluation of an allocator for a given
access type, it depends on each master that includes the elaboration
of the declaration of the ultimate ancestor of the given access type."

The language here may be a bit sloppy, since for an anonymous access
type, I'm not sure there's any such thing as "the declaration of
... [a] given access type".  However, if this is interpreted as "the
declaration that causes the access type to be defined", then for
Make_ER, the declaration referred to is the extended return object
declaration, because that's the type that the allocator returns:

  Return Result : Not Null Access Testing:= New Testing(New String'(Input));

However, for Make_EF and Make_NR, the declaration is the function
declaration.  In Make_ER, the master that elaborates the extended
return object declaration (and therefore the anonymous access type
declaration) is the body of Make_ER.  (For the other cases, the
master that elaborates the declaration is the Experiment procedure.)

The upshot of all this is that, by 7.6.1(4) and 9.3(2), in Make_ER,
the task created by the allocator *depends* *on* the body of Make_ER,
and therefore the body of Make_ER cannot complete until the task has
completed.  That should be enough to explain the results.

The moral: Whether or not you think anonymous access types are evil,
anonymous access types to *tasks* definitely can have some surprising
consequences (because of the task termination and dependency rules),
and should be avoided.

                         -- Adam