On Sat, May 05, 2001 at 03:35:40PM -0400, Cliff Woolley wrote: > On Sat, 5 May 2001, Ralf S. Engelschall wrote: > > > > > A wish to our APR hackers: > > > > For mod_ssl and certainly also for other purposes we really need shared > > memory based apr_pool_t's, i.e., pools which allocate their memory not > > from the heap but from a shared memory segment. This would allow us to > > complete kick out the large 100KB third-party ssl_util_table.* stuff by > > using just a standard APR hash inside an APR pool which is located in a > > shared memory segment. For EAPI in Apache 1.3 there was a patch against > > alloc.c which provided such a functionality, although mod_ssl was never > > adjusted to use this feature directly. > > Sounds like the SMS (stackable memory system) stuff that the Samba-TNG > guys have proposed for APR might be worth some investigation...
just posted about this, on [EMAIL PROTECTED] there are unique issues to do with setting up a shared-memory apr_pool_t. namely, that the paradigm doesn't work :) you will need to add an extra function that allows you to enumerate through all allocated memory blocks, returning to 'you, the user' all addresses and sizes of all blocks allocated so far within a specific shared memory block. in this way, you can have one program ap_pool_alloc() several blocks, and then have another program or programs obtain the addresses of those blocks, without interference between the programs. this is pretty ugly, but to be honest, within the paradigm of the apr_pool_xxx() API, i don't see another way to do it. [i am assuming that you know how a shmem-based apr_pool_t, using apr_memsys, or even if it didn't use apr_memsys, would work. please let me know, via the dev@apr.apache.org list, once read my last posting on the subject, if you don't. i have very bad rsi and only getting worse: typing is therefore at a minimum. thx.] luke
