Re: Help-memory allocation

["Robert I. Eachus" <rieachus@attbi.com>]

Vinzent Hoefler wrote:
 > Mmh, so in case someone relies on the occurence of the exception in
> the very moment of the allocation, would it be wise to also give an
> initial value to make sure we actually "use" the allocated memory?

Dave Emery likes to describe Storage_Error as a parachute that opens on 
impact.  The problem is not in the definition of allocators, but that 
there may be temporary storage used when evaluating an expression.  So 
the allocator can use up almost but not quite all of the storage, and 
you will then get a Storage_Error exception somewhere downstream.

Unless you carefully track how much storage is used by your program and 
where, you have to allow for the possibility of Storage_Error anywhere. 
  Of course, on a decent virtual memory system, most programs will use 
so little memory compared to the (virtual) Gigabytes allocated to that 
process that Storage_Error will only occur if you run out of disk space.

There are cases in Ada where handling Storage_Error is useful.  For 
example if you are potentially creating a large object on the stack, not 
the heap.  But in other cases all Storage_Error tells you is that you 
crashed.  Actually, there is an even worse case.  You can have a handler 
for Storage_Error in just the right place, and catch Storage_Error when 
it occurs--but then the exception handler uses some memory and boom! 
Storage_Error is raised again, outside the error handler.  Nice OSes 
save a block at the end of the stack which is released when a stack 
allocation error occurs so that the first Storage_Error can be handled 
nicely.  But such a block can only be used reliably once per process.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.