apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Kenneth Casson Leighton <l...@samba-tng.org>
Subject Re: Observations on fragmentation in SMS pools
Date Mon, 09 Jul 2001 15:49:24 GMT
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


Mime
View raw message