From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,93211508cf0a6c34 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!peer01.cox.net!cox.net!p02!dukeread02.POSTED!53ab2750!not-for-mail From: Dan Baysinger User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Memory Mapped Storage Pools. References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Tue, 25 Oct 2005 20:41:05 -0500 NNTP-Posting-Host: 68.97.45.26 X-Complaints-To: abuse@cox.net X-Trace: dukeread02 1130290857 68.97.45.26 (Tue, 25 Oct 2005 21:40:57 EDT) NNTP-Posting-Date: Tue, 25 Oct 2005 21:40:57 EDT Organization: Cox Communications Xref: g2news1.google.com comp.lang.ada:5950 Date: 2005-10-25T20:41:05-05:00 List-Id: 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