!standard 13.11.5(5/3)                                    19-05-10  AI12-0331-1/02
!standard 13.11.5(6/3)
!standard 13.11.5(7/3)
!standard 13.11.5(7.1/4)
!standard 13.11.5(8/3) 
!standard 13.11.5(9/3) 
!class binding interpretation 19-05-07
!status Amendment 1-2012 19-05-09
!status WG9 Approved 22-06-22
!status ARG Approved 9-0-0  19-05-09
!status work item 19-05-07
!status received 19-04-03
!priority Low
!difficulty Easy
!qualifier Clarification
!subject Order of finalization of a subpool
!summary

The finalization of a subpool proceeds in four distinct steps.

!question

13.11.5(5/3) defines what happens when a subpool is finalized, but some
of the effects have to be performed before others (the objects had better
be finalized before they cease to exist, for instance). Should this text be
clarified? (Yes.)

!recommendation

(See Summary.)

!wording

Replace 13.11.5(5-9/3) with:

Finalization of a subpool has the following effects:

1. Any of the objects allocated from the subpool that still exist are 
   finalized in an arbitrary order;

2. All of the objects allocated from the subpool cease to exist;

3. The following [dispatching] call is then made: 

   Deallocate_Subpool(Pool_of_Subpool(Subpool).all, Subpool);

4. The subpool ceases to  belong to any pool.

!discussion

The wording for Unchecked_Deallocation is clearly written with an order in
mind. The rules for finalization of a subpool should use a similar order.

Finalization of objects has to happen before they cease to exist. The objects
have to cease to exist before any memory is deallocated (meaning that has
to happen before Deallocate_Subpool is called).

Deallocate_Subpool has to be called before the subpool no longer belongs to 
any pool, because severing that connection would cause Pool_of_Subpool to
return null. Thus we get the order given above.

!corrigendum 13.11.5(5/3)

@drepl
Finalization of a subpool has the following effects:
@dby
Finalization of a subpool has the following effects in the given order:

!corrigendum 13.11.5(6/3)

@ddel
@xbullet<The subpool no longer belongs to any pool;>

!corrigendum 13.11.5(7/3)

@drepl
@xbullet<Any of the objects allocated from the subpool that still exist
are finalized in an arbitrary order;>
@dby
@xhang<@xterm<1.>Any of the objects allocated from the subpool that still 
exist are finalized in an arbitrary order;>

!corrigendum 13.11.5(7.1/4)

@drepl
@xbullet<All of the objects allocated from the subpool cease to exist;>
@dby
@xhang<@xterm<2.>All of the objects allocated from the subpool cease to 
exist;>

!corrigendum 13.11.5(8/3)

@drepl
@xbullet<The following dispatching call is then made:>
@dby
@xhang<@xterm<3.>The following dispatching call is then made:>

!corrigendum 13.11.5(9/3)

@dinsa
@xindent<@fc<    Deallocate_Subpool(Pool_of_Subpool(Subpool).@b<all>, Subpool);>>
@dinst
@xhang<@xterm<4.>The subpool ceases to belong to any pool.>
!ASIS

No ASIS effect.

!ACATS test

No separate ACATS test should be needed, as this is the only sensible order 
and the steps are not separately testable.

!appendix

From: Randy Brukardt
Sent: Wednesday, April 3, 2019  12:53 AM

Brad's RM review includes:

> 13.11.5 (5/3) says; "Finalization of a subpool has the following 
> effects:"
> followed by 4 bullets. This wording suggests 4 things result from the 
> finalization, but doesn't really state the the list of bullets occur 
> in any order, when in fact a top-down order is needed for the bullets 
> to make sense.
> 
> I think it would eliminate some confusion if 13.11.5(5/3) were changed 
> like;
> 
> "Finalization of a subpool takes place as follows:
> Then replace the 4 bullets  of 13.11.5(6/3-8/3) with numbers 1.
> 2.
> 3.
> 4.

His proposed solution doesn't make sense, since the first bullet is "the 
subpool no longer belongs to any pool". And the last bullet is "The following 
dispatching call is made:
    Deallocate_Subpool(Pool_of_Subpool(Subpool).all, Subpool);

If the first bullet is True, Pool_of_Subpool will return null, so the 
dispatching call would raise Constraint_Error if done after the first bullet.

But Brad is definitely correct that there is an implied order in some of 
these bullets. One better finalize the objects *before* they cease to exist, 
and as noted above, the subpool shouldn't be detached from the pool until 
after the call to Deallocate_Subpool.

Something is confused here.

This seems too unimportant to worry about now (unless there is a volunteer 
that wants to work on it ASAP), but it probably should be addressed in a 
Binding Interpretation sometime reasonably soon. (Note that there is no 
new rules in this; the last change was in the 2016 Corrigendum.)

****************************************************************

From: Steve Baird
Sent: Wednesday, April 3, 2019  6:24 PM

> This seems too unimportant to worry about now (unless there is a 
> volunteer that wants to work on it ASAP), but it probably should be 
> addressed in a Binding Interpretation sometime reasonably soon.

Agreed on all counts.

We've got 4 effects listed:

   The subpool no longer belongs to any pool;

   Any of the objects allocated from the subpool that still exist are
   finalized in an arbitrary order;

   All of the objects allocated from the subpool cease to exist;

   The following [dispatching] call is then made:
     Deallocate_Subpool(Pool_of_Subpool(Subpool).all, Subpool);

Which of the other 3 effects listed are consequences of the last one?

When you look in 13.11.4 to see what Deallocate_Subpool does (or is required
to do), there isn't really a precise description.
AARM text says:

  Deallocate_Subpool is expected to do whatever is needed to deallocate
  all of the objects contained in the subpool

That seems vague. For example, one could interpret that to mean that 
finalization of any objects allocated from the subpool is to be performed, 
although I don't think that is the intent.

But I agree on the main point - no need to do anything right now.

****************************************************************

From: Randy Brukardt
Sent: Wednesday, April 3, 2019  6:50 PM

> We've got 4 effects listed:
> 
>    The subpool no longer belongs to any pool;
> 
>    Any of the objects allocated from the subpool that still exist are
>    finalized in an arbitrary order;
> 
>    All of the objects allocated from the subpool cease to exist;
> 
>    The following [dispatching] call is then made:
>      Deallocate_Subpool(Pool_of_Subpool(Subpool).all, Subpool);
> 
> Which of the other 3 effects listed are consequences of the last one?

None, so far as I know. But clearly the first effect has to happen after the 
last effect, or the call would fail. And the finalization has to happen 
before the objects cease to exist. Most likely, we want the dispatching call 
to occur after finalization, and about the same time as the objects cease to 
exist, since it might be trying to free the memory those objects used. So if 
we wanted to say these occur in a specific order (and that probably would be 
best), the order given isn't the right one.

I think the definition of Deallocate_Subpool is intentionally vague, since 
its main purpose is to allow the subpool creator to do whatever they want at
this point. The language-defined things (like finalization) are done by the 
implementation before it is called; those are never user-defined code's 
responsibility. (As with the regular Deallocate.)

****************************************************************