Version 1.3 of ai05s/ai05-0189-1.txt
!standard D.7 (19.1/2) 09-11-03 AI05-0189-1/01
!class amendment 09-11-03
!status work item 09-11-03
!status received 09-11-03
!priority Low
!difficulty Easy
!subject Restriction No_Allocators_After_Elaboration
!summary
Provide a restriction that disallows use of allocators after
library unit elaboration is complete.
!problem
It is quite common that a resource-constrained long-lived application wants to
avoid any heap allocation after library unit elaboration is complete,
to ensure that there is no heap growth during the ongoing execution of
the program.
!proposal
(see summary)
!wording
Add after D.7(19.1/2):
No_Allocators_After_Elaboration
Specifies that the only allocators that may be evaluated during the
execution of the partition are within the execution of the
environment task, during the elaboration of the library_items of
the partition, prior to the invocation of any main subprogram. An
allocator shall not occur within a task body or the main
subprogram. If an implementation chooses to detect a violation of
this restriction at run-time, Storage_Error should be raised;
otherwise the behavior is implementation defined.
!discussion
For simplicity, we have restricted allocators to the environment task,
even though it might be possible for a non-environment task to execute
entirely during library-item elaboration. This also eliminates the need
for synchronization during heap allocation.
We do not require this restriction to be entirely enforced prior to
execution. We perhaps could do so, but to do it completely
could require significant static analysis.
!examples
** TBD **
!ACATS test
ACATS B and C tests are needed.
!appendix
From: Tucker Taft
Sent: Friday, June 12, 2009 6:23 AM
This is an official request from Ada Switzerland for a restriction that
disallows allocation after library-unit elaboration is complete.
[Editor's note: Not sure when Tucker becaome Swiss! I presume he meant to
say that he is relaying an official request from Ada Switzerland, or some
such thing.]
****************************************************************
From: Jean-Pierre Rosen
Sent: Friday, June 12, 2009 12:05 PM
No_Local_Allocator seems to come close...
****************************************************************
From: Tucker Taft
Sent: Friday, June 12, 2009 3:44 PM
True, but it is too limiting. It means that you can't use allocators in
subprograms, even if they are called only during library-unit elaboration.
That pretty much defeats any kind of abstraction.
Many embedded systems have the model of allowing dynamic allocation during
start up, but not thereafter. Ada really ought to support that. What I would
imagine is a restriction that disallows use of a default storage pool after
elaboration is complete, while allowing user-defined storage pools to check
in the Allocate procedure against some global flag that indicates whether
library-level elaboration is complete.
****************************************************************
From: Tullio Vardanega
Sent: Saturday, June 13, 2009 3:05 AM
Something along the line of Tucker's outline would be very useful indeed.
At present we often find ourselves in the need of cheating ourselves and
the compiler by removing pragma Restrictions to permit the elaboration code
to use dynamic memory allocation, but in that manner we lose the ability to
enforce the restriction for the code executed after elaboration.
****************************************************************
Questions? Ask the ACAA Technical Agent