apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Travis <jtra...@covalent.net>
Subject Re: Observations on fragmentation in SMS pools
Date Mon, 09 Jul 2001 16:22:13 GMT
On Mon, Jul 09, 2001 at 05:49:24PM +0200, Luke Kenneth Casson Leighton wrote:
> 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.
> 

The apr_table_t is just an apr_array_header_t with a specific
key/val entry type.

> 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?

I think you are in for a ride on this one.  The API for dealing
with the tables is currently rather poor, since typically it
is casted to an array and then iterated over.  The strcasecmp's
of the table code are a whole seperate issue.  I would think that
the (nearly analagous) apr_hash_t would better suit what you
are talking about here.  

BTW: Why are tables in APR at all?  The only thing I see used
is headers in apr-util hooks code, and in the xml, but that of
course can be fixed.  Step 1, remove tables from APR, Step 2, 
remove tables from Apache.

-- Jon


Mime
View raw message