Contents Index Search Previous Next
7.6.1 Completion and Finalization
1
This subclause defines
completion and
leaving
of the execution of constructs and entities. A
master is the execution
of a construct that includes finalization of local objects after it is
complete (and after waiting for any local tasks -- see
9.3),
but before leaving. Other constructs and entities are left immediately
upon completion.
Dynamic Semantics
2
The execution
of a construct or entity is
complete when the end of that execution
has been reached, or when a transfer of control (see
5.1)
causes it to be abandoned.
Completion
due to reaching the end of execution, or due to the transfer of control
of an
exit_,
return_,
goto_, or
requeue_statement
or of the selection of a
terminate_alternative
is
normal completion. Completion is
abnormal otherwise
-- when control is transferred out of a construct due to abort or the
raising of an exception.
3
After
execution of a construct or entity is complete, it is
left, meaning
that execution continues with the next action, as defined for the execution
that is taking place.
Leaving an execution happens
immediately after its completion, except in the case of a
master:
the execution of a
task_body, a
block_statement, a
subprogram_body,
an
entry_body, or an
accept_statement.
A master is finalized after it is complete, and before it is left.
4
For the
finalization
of a master, dependent tasks are first awaited, as explained in
9.3.
Then each object whose accessibility level is the same as that of the
master is finalized if the object was successfully initialized and still
exists. These actions are performed whether the master is left by reaching
the last statement or via a transfer of control. When a transfer of control
causes completion of an execution, each included master is finalized
in order, from innermost outward.
5
For
the
finalization of an object:
6
- If the object is of an elementary
type, finalization has no effect;
7
- If the object is of a controlled type,
the Finalize procedure is called;
8
- If the object is of a protected type,
the actions defined in 9.4 are performed;
9
- If the object is of a composite type,
then after performing the above actions, if any, every component of the
object is finalized in an arbitrary order, except as follows: if the
object has a component with an access discriminant constrained by a per-object
expression, this component is finalized before any components that do
not have such discriminants; for an object with several components with
such a discriminant, they are finalized in the reverse of the order of
their component_declarations.
10
Immediately before an instance
of Unchecked_Deallocation reclaims the storage of an object, the object
is finalized. If an instance of Unchecked_Deallocation is never applied
to an object created by an
allocator,
the object will still exist when the corresponding master completes,
and it will be finalized then.
11
The order in which the finalization of a master
performs finalization of objects is as follows: Objects created by declarations
in the master are finalized in the reverse order of their creation. For
objects that were created by
allocators
for an access type whose ultimate ancestor is declared in the master,
this rule is applied as though each such object that still exists had
been created in an arbitrary order at the first freezing point (see
13.14)
of the ultimate ancestor type.
12
The target of an assignment
statement is finalized before copying in the new value, as explained
in
7.6.
13/1
If the object_name
in an object_renaming_declaration,
or the actual parameter for a generic formal in out parameter
in a generic_instantiation, denotes
any part of an anonymous object created by a function call, the anonymous
object is not finalized until after it is no longer accessible via any
name. Otherwise, an anonymous object created by a function call or by
an aggregate is finalized no later
than the end of the innermost enclosing declarative_item
or statement; if that is a compound_statement,
the object is finalized before starting the execution of any statement
within the compound_statement.
13.1/1
If a transfer of control or raising of an
exception occurs prior to performing a finalization of an anonymous object,
the anonymous object is finalized as part of the finalizations due to
be performed for the object's innermost enclosing master.
Bounded (Run-Time) Errors
14/1
It
is a bounded error for a call on Finalize or Adjust that occurs as part
of object finalization or assignment to propagate an exception. The possible
consequences depend on what action invoked the Finalize or Adjust operation:
15
- For a Finalize
invoked as part of an assignment_statement,
Program_Error is raised at that point.
16/1
- For an Adjust invoked as part of the
initialization of a controlled object, other adjustments due to be performed
might or might not be performed, and then Program_Error is raised. During
its propagation, finalization might or might not be applied to objects
whose Adjust failed. For an Adjust invoked as part
of an assignment statement, any other adjustments due to be performed
are performed, and then Program_Error is raised.
17
- For a Finalize
invoked as part of a call on an instance of Unchecked_Deallocation, any
other finalizations due to be performed are performed, and then Program_Error
is raised.
17.1/1
- For a Finalize
invoked as part of the finalization of the anonymous object created by
a function call or aggregate, any
other finalizations due to be performed are performed, and then Program_Error
is raised.
17.2/1
- For a Finalize
invoked due to reaching the end of the execution of a master, any other
finalizations associated with the master are performed, and Program_Error
is raised immediately after leaving the master.
18
- For a Finalize
invoked by the transfer of control of an exit_,
return_, goto_,
or requeue_statement, Program_Error
is raised no earlier than after the finalization of the master being
finalized when the exception occurred, and no later than the point where
normal execution would have continued. Any other finalizations due to
be performed up to that point are performed before raising Program_Error.
19
- For a Finalize invoked by a transfer
of control that is due to raising an exception, any other finalizations
due to be performed for the same master are performed; Program_Error
is raised immediately after leaving the master.
20
- For a Finalize invoked by a transfer
of control due to an abort or selection of a terminate alternative, the
exception is ignored; any other finalizations due to be performed are
performed.
21
18 The rules of Section
10 imply that immediately prior to partition termination, Finalize operations
are applied to library-level controlled objects (including those created
by allocators of library-level access
types, except those already finalized). This occurs after waiting for
library-level tasks to terminate.
22
19 A constant is only constant
between its initialization and finalization. Both initialization and
finalization are allowed to change the value of a constant.
23
20 Abort is deferred during
certain operations related to controlled types, as explained in 9.8.
Those rules prevent an abort from causing a controlled object to be left
in an ill-defined state.
24
21 The Finalize procedure
is called upon finalization of a controlled object, even if Finalize
was called earlier, either explicitly or as part of an assignment; hence,
if a controlled type is visibly controlled (implying that its Finalize
primitive is directly callable), or is nonlimited (implying that assignment
is allowed), its Finalize procedure should be designed to have no ill
effect if it is applied a second time to the same object.
Contents Index Search Previous Next Legal