apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@covalent.net>
Subject Re: cvs commit: apr-util/misc apr_rmm.c Makefile.in
Date Sat, 05 Jan 2002 07:25:04 GMT
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

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 :)


----- Original Message ----- 
From: <wrowe@apache.org>
To: <apr-util-cvs@apache.org>
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.

View raw message