Re: Memory Mapped Storage Pools.

[Dan Baysinger <baysinger@earthlink.net>]

I use mmap'ed storage for essentially the same reasons that you gave. 
However, I just derived from System.Storage_Pools.Root_Storage_Pool and 
  overrode all of the subprograms to allocate the requested objects 
using mmap and deallocate with unmap.

The Root_Storage _Pool type was extended with a private pointer to a 
linked list of allocations made for the client's storage pool.  I used 
an opaque type (incomplete declaration in the spec's private area and 
completion in the body) for the elements of the allocation linked list 
to discourage (not actually prevent) users from trying to manipulate the 
allocations directly.

You need to override finalization so that it walks the allocation list 
and unmaps all allocations for the user's storage pool.

Also, I mmapped to /dev/zero so that an actual file was not created.

This has worked quite well for my purposes, and its usage is completely 
compatible with the storage_pool specification for access types, the 
'new' allocator, and Ada.Unchecked_Deallocation.  From the user's 
perspective the behavior is identical to that of a storage pool created 
System.Storage_Pools.Root_Storage_Pool.

Dan Baysinger




Freejack wrote:

> Ada Storage Pools, in Unix/Posix type environments, are typically
> handled via the omnipresent C malloc() routine. While this undoubtedly
> simplifies compiler/runtime development, it has left me desiring a
> mechanism with a bit more control.
> 
> So I've begun working on a library that allocates storage pools through
> the lower level mmap() suite of system utilities. I'm tentatively calling
> it Custom_Storage.Mapped_Pools
> 
> It's intended use is for very large allocations that are intended to be
> returned to the system upon finalization, rather than having the extra
> memory linger in the program's process "space".
> 
> Such a package's interfaces need to be carefully designed so as to prevent
> it's client developers from going ape shit every time  they need a clear
> definition of exactly what the routine is going to do to the rest of their
> process space. Hence I would like some advice. How would you like to see
> such a package laid out? Should I make a set of thick or thin bindings to
> the mmap() facilities to go along with the Mapped_Pools package? What
> things should I keep in mind as to making the package portable to other
> environments with an mmap() facility?
> 
> Any tips would be appreciated.
> 
> Freejack