From dev-return-3140-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Mon Jul 09 15:50:20 2001 Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 31575 invoked by uid 500); 9 Jul 2001 15:50:13 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 31421 invoked from network); 9 Jul 2001 15:50:09 -0000 Date: Mon, 9 Jul 2001 17:49:24 +0200 From: Luke Kenneth Casson Leighton To: Justin Erenkrantz Cc: Jon Travis , Sander Striker , apr-dev@apache.org Subject: Re: Observations on fragmentation in SMS pools Message-ID: <20010709174924.E16182@angua.rince.de> References: <20010708103422.A15223@covalent.net> <20010708110409.B15260@covalent.net> <20010708110633.V28500@ebuilt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20010708110633.V28500@ebuilt.com>; from jerenkrantz@ebuilt.com on Sun, Jul 08, 2001 at 11:06:33AM -0700 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N On Sun, Jul 08, 2001 at 11:06:33AM -0700, Justin Erenkrantz wrote: > On Sun, Jul 08, 2001 at 11:04:09AM -0700, Jon Travis wrote: > > As for the ability to use shared memory for this ... yeah that is > > an interesting idea. What are your actual use cases for that? > > Ian posted a patch to do something like this - I think he wanted a hash > table that was shared across all processes. The problem gets to be > growing the memory space, but I think his use case was with fixed > memory. He could probably tell more about how he wanted to do it. > > Both rbb and I suggested that this is what SMS was designed for. > Have a SMS that is backed by shared memory and then the hashtable > immediately becomes shared when you create it with this shared memory > SMS. No change needed to the hashtable code. okay, had an idea here that i thought i'd share with you about shmem/pools/sms. lessons from tdb's design. accessing shmem, you really have to treat it as a very-fast-file-in-memory. therefore, best thing to do to be able to easily access sections of it: treat the shmem as an in-memory database. the simplest way to fit that into the existing APR code is to have direct support for apr_table_t in a pool-based or sms-based shared-memory-segment. if you examine tdb.c's design, you will notice that apr_table_do() becomes identical to [but more powerful than] tdb_traverse(). apr_array_header_t? again, i haven't thought about it, but you could likely get away with the same thing. in other words, i think that supporting apr_pool_t on top of shared memory (via sms) is going to be tricky: in my opinion, the apr_pool_xxx() API _and_ the apr_sms_xxx() API can't Deal With shared memory at a convenient user-acceptable level. HOWEVER! supporting the data types that apr_pool_xxx() USES is a different matter. by supporting apr_array_header_t (if possible) and apr_table_t the complexity of messing about will be hidden from users of these data types, but they will work quite happily as expected, even if it's shared memory behind them. what people think? luke