Some quick credits where credit is due, thanks to David for his very thorough beos/apr_shmem.c implementation (and to whomever inspired that code), for at least a good outline and little reminders of structure... and to Aaron, Justin, Sander and Ian for sounding boards.
And if you want to float ideas or discuss apr design... we'd all like to invite you [again] to join us over at irc.openprojects.net, the #apr home hacking channel :) It really helped to coallesce some ideas [now open for discussion and patching] before this was thrown out 1/2 thought out. Warning to implementors; we will aquire a lock to go with this, and register it with apr_rmm_init or apr_rmm_attach. The first question; who is responsible for creating the lock? Some folks won't need locks at all (only the controlling process/thread would ever alloc/dealloc.) Some will need an intraprocess lock, since only the one process (many of it's threads, however) will be messing with allocations. And some will need full interprocess locks so everyone can get their fingers dirty. Since the actually apr_lock_t is location-process-dependent, we can't simply throw the lock into the rmm memory space. We need to pass in some descriptor that apr_rmm_attach() can use to obtain it's own private copy of that same lock. Maybe it's time to look at an accessor API for serializing and recomposing apr types, to pass from process to process [Win32 needs this, very badly.] And if you object to the name apr_rmm, be warned, most alternatives were real groaners :) Bill ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, January 05, 2002 1:14 AM Subject: cvs commit: apr-util/misc apr_rmm.c Makefile.in > wrowe 02/01/04 23:14:29 > > Modified: . CHANGES aprutil.dsp libaprutil.dsp > misc Makefile.in > Added: include apr_rmm.h > misc apr_rmm.c > Log: > A minimalist relocatable memory manager. When I suggest minimalist, > it is -minimal-, still missing locking for allocation [that gets tricky, > we can discuss on list], some get largest-available and get free space > APIs, a get_management_overhead call [for determining the optimal > preallocation size before creating a block of memory to manage] > and a better-fit algorithm so we make best use of tight spaces. > > This also should grow a set of typesafe offset-protection wrappers, > which I will introduce shortly. Those have proven trickier than I > had expected. > > While this is designed for Aaron's redesign of shm, it certainly > isn't limited to that application. It is great for serializing any > sort of structures into files or between processes, or other > persistant applications.
