CVS difference for ais/ai-30302.txt

Differences between 1.21 and version 1.22
Log of other versions for file ais/ai-30302.txt

--- ais/ai-30302.txt	2006/02/21 04:22:05	1.21
+++ ais/ai-30302.txt	2006/03/18 06:52:08	1.22
@@ -33338,185 +33338,3 @@
 
 ****************************************************************
 
-From: Bibb Latting
-Sent: Thursday, February 9, 2006  1:31 PM
-
-!topic Control over storage pool underlying Ada.Containers packages
-!reference Ada 2005 RMA.18(all)
-!from Bibb Latting 05-02-09
-!keywords Containers, Storage Pools
-!discussion
- 
-The capability to use a derivation of root_storage_pool with a container
-is desired to provide flexibility in the management of the storage
-underlying the container.  This capability provides the opportunity for
-the user to optimize memory allocation for a given application, work-around
-fragmentation in the hardware mapping of memory, provide non-core memory
-allocation of the container, or to comply with safety/security issues.
- 
-Please feel free to change the above discussion as desired.
- 
-****************************************************************
-
-From: Tucker Taft
-Sent: Thursday, February 9, 2006  1:58 PM
-
-The general consensus on this suggestion was that it
-is good, but would involve significant analysis to
-get it right at this point.  A recommendation was to
-leave it out of the standard, but encourage implementations
-to support the capability.  In general the Containers
-packages were designed to be a starting point, not
-the final story.  Ordered_ and Hashed_ might easily be
-augmented with numerous other capabilities, including
-"Bounded_...", "Protected_...", "Pooled_...", etc.
-So long as all the packages have nearly identical
-contents, it isn't too bad to have implementation-specific
-code at the point of the instantiation.  The large
-bulk of the user's code will depend only on the package
-contents, not its instantiation parameters, and reasonable
-portability can be preserved.
-
-****************************************************************
-
-From: Randy Brukardt
-Sent: Thursday, February 9, 2006  3:22 PM
-
-The deadline for informal comments on Ada 2005 was last Friday. At this
-point, only editorial comments will be accepted. There may be an opportunity
-for formal comments at some point later in the future (although the primary
-effect of such comments would be to endanger the future of the Amendment and
-potentially of Ada itself).
-
-So, at the point we're primarily talking about future work (beyond Ada
-2005).
-
-In any case, there are a number of reasons that user-defined storage pools
-are inappropriate for the unbounded containers that Ada 2005 has:
-
-1) There is no good way to name the default storage pool. Thus, there is no
-good way to specify the default case of using the default storage pool. We
-definitely do not want to make instantiating these containers harder.
-
-Note that we tried early in the Ada 2005 process (see AI-300) to find a way
-to make the default pool available. However, it ran into opposition from
-some ARG members, who noted that some implementations used multiple default
-storage pools, tailored to the characteristics of the type. That model
-doesn't make it easy to name the default pool. The issue died because no
-solution that worked for such a model could be found.
-
-2) Although it's counter-intuitive, allowing user-defined storage pools
-makes the containers less safe. The containers are almost certainly going to
-be implemented as controlled types. If the storage pool has some method
-other than Deallocate for freeing memory (before the pool itself ceases to
-exist) -- and many user-defined pools do -- that could free memory belonging
-to container objects and subparts. When those objects are later finalized,
-the world will end, as the finalization information could very well have
-been destroyed. (For instance, Janus/Ada chains together controlled objects;
-if the memory is prematurely freed, those chains can be destroyed, and
-almost anything could happen, none of it good.)
-
-This problem cannot happen with the standard storage pool.
-
-One could try to mitigate this problem by trying to define when it would be
-safe to do premature deallocation, but such wording would also have the
-effect of banning useful implementation techniques (such as caching of
-nodes).
-
-We'd also have to add wording to take into account this possibility. That
-would make the containers *appear* less safe than they currently are, by
-adding additional cases of erroneous behavior. Some reviewers were extremely
-concerned about erroneous behavior of the containers, and we spent a lot of
-effort eliminating as much such behavior as possible.
-
-Aside: We'd also need wording to allow any operation to call Allocate, and
-to require the propagation of any exceptions it generates. We don't need
-special wording for the standard storage pool, because all it can do is
-propagate Storage_Error, and *any* operation in Ada is *always* allowed to
-do that. So no extra wording is needed.
-
-3) The unbounded forms can (and often have to) allocate pretty much any size
-or shape of memory as part of pretty much any operation. For instance, a
-vector container (depending on it's implementation) could allocate
-individual elements, small "chunks" of elements, or the entire data array of
-elements at one time. Putting limits on that would be inappropriate for the
-unbounded containers - we want to encourage innovative implementations.
-Thus, any pool used with the unbounded containers would need to allow
-arbitrary-sized allocations.
-
-The effect of (2) and (3) is that many useful storage pools couldn't be used
-in the context of the unbounded containers. A pool that is used to manage
-memory would be inappropriate; it could only manage memory when no container
-instantiation exists, and at that point no memory is allocated anyway. A
-pool that does not allow any size allocation also cannot be used. For
-instance, a pool that only allows specific sizes of allocations to eliminate
-fragmentation could not be used in the context of the unbounded containers.
-
-That doesn't leave many useful pools that could be used with the unbounded
-containers. A pool that simply records the memory use could be used, and an
-alternative heap could be used, but that's about it. That didn't seem like
-enough to be worth the additional complication.
-
-OTOH, it makes perfect sense for other forms of container to provide this
-sort of functionality. The intent (as Tucker pointed out) is that the
-containers in Ada 2005 provide a starting point for Ada containers, not be
-the end point. We certainly hope that additional forms of containers are
-developed for future use. (Hopefully, that would contain a solution to (1),
-as well.)
-
-One of the things that we'll be doing in future months is considering where
-we need future work. Certainly, there has been a lot of interest in other
-containers and other forms of containers (such as Bounded), so that will be
-considered. And, as these are separate packages, there is no need to wait
-another 10 years to standardize them. Moreover, these packages are
-relatively easy for implementers to provide, so I would expect that most
-implementers will do so. But we'll need energetic people (like Matt Heaney
-was for the current set of containers) to participate and draft all of the
-tedious wording needed. (A thick skin, to survive the constant nit-picking
-at their hard work, also is a prerequisite.)
-
-****************************************************************
-
-From: Robert A. Duff
-Sent: Thursday, February 9, 2006  4:54 PM
-
->...The containers are almost certainly going to
-> be implemented as controlled types. If the storage pool has some method
-> other than Deallocate for freeing memory (before the pool itself ceases to
-> exist) -- and many user-defined pools do -- that could free memory belonging
-> to container objects and subparts.
-
-The container type has finalization.  The heap-allocated memory blocks do not
-(unless the actual element type passed in does).  So it would be OK
-to use a user-def pool, so long as the element type does not have
-controlled parts.
-
-Anyway, I agree with what Tuck and Randy said: allowing user-def pools is a
-good idea, but for the future (after Ada 2005).
-
-****************************************************************
-
-From: Randy Brukardt
-Sent: Thursday, February 9, 2006  5:10 PM
-
-Huh? If the heap-allocated blocks are linked together (certainly will be
-true in the list container, probably in most of the others too), when the
-finalization routine walks the blocks whose memory has been reused to free
-them, the results won't be pretty.
-
-We certainly don't want to be mandating implementations that don't include
-any links (that would be a major change for the unbounded containers, and
-would make it very hard to implement the intended semantics). So I don't see
-how one could expect such a pool to work at any time than when no container
-objects exist. And even that prevents node caching.
-
-****************************************************************
-
-From: Robert A. Duff
-Sent: Thursday, February 9, 2006  5:53 PM
-
-Yes, you're right.  I was confused.
-
-****************************************************************
-
-

Questions? Ask the ACAA Technical Agent