apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <i...@cnet.com>
Subject Re: [PATCH/CONTRIB] Shared Mem Hash Table
Date Thu, 05 Jul 2001 16:14:56 GMT
oops...forgot the list.
On 05 Jul 2001 09:14:03 -0700, Ian Holsman wrote:
> On 05 Jul 2001 08:46:05 -0700, rbb@covalent.net wrote:
> > On 5 Jul 2001, Ian Holsman wrote:
> > 
> > > On 04 Jul 2001 21:16:56 -0700, Justin Erenkrantz wrote:
> > > > On Wed, Jul 04, 2001 at 09:01:35PM -0700, Ian Holsman wrote:
> > > > > This implements a hash table using shared memory.
> > > > > Limitations:
> > > > >     * doesn't have a freelist, so deletes aren't reclaimed
> > > > >     * and can't expand it's size (dont know how to implement this
with
> > > > > current shared memory system)
> > > > >     * no locking (yet)
> > > > > It is intended for use in modules having a large config requirements
> > > > > (Patches inline, extra files attached)
> > > > >
> > > > > It is intented that apr_shm_hash.c will live in apr/tables
> > > > >     apr_shm_hash.h in apr/include
> > > > > &
> > > > >     testhash.c in apr/test
> > > >
> > > > Cool.  Can we revisit this once we have reworked the apr_shm interface?
> > > > I guess someone could commit this now, but it might make sense to hold
> > > > off until we have a decent SHM interface.  And, ideally SHM could/should
> > > > be implemented around SMS.  If so, that might change how this is
> > > > implemented.  -- justin
> > >
> > > In the conversations I have seen SMS was always talked about post 2.0
> > > Release.
> > > Is this still the case?
> > 
> > Nobody knows.  There are a lot of people focusing on the SMS code, so that
> > means it is likely to be ready soon.  Regardless, adding a shared memory
> > hash is a dangerous thing for us to do.  We need to support that API
> > forever.  We know already that we want to solve this problem with a shared
> > memory SMS, and our current hash code.  I would much rather not litter our
> > API with functions that we know we don't want to support for very long.
> > 
> 
> Cool... I'll just implement the patch privately.
> 
> as a side note;
> I don't see how you plan on implementing any kind of dynamic structure
> via a shared-memory SMS which will look to the rest of the code just the
> same as a non-shared-memory SMS. 
> 
> the basic problem I see is that you will not be able to 'point' to
> memory in a Shared SMS, just offsets.
> 
> so your code which would call the SMS would have to have 2 different
> implementations. 
> 
> the other problem is that you can't just allocated another block when
> you run out of space in your first one, as the memory allocated for the
> second block may not be the at the same offset from your original one
> cross process.
> 
> so I guess what i am rambling about is that the type of memory returned
> would be completly different than the current SMS allocators, and you
> would need different data structures to handle these different types of
> memory, so I am still unsure on how you would have set of 'hash'
> functions which would work on both types unless you implement the
> structures without pointers and only use offsets within one memory
> block.
> 
> ..ian
> 
> > Ryan
> > 
> > _____________________________________________________________________________
> > Ryan Bloom                        	rbb@apache.org
> > Covalent Technologies			rbb@covalent.net
> > -----------------------------------------------------------------------------
> 



Mime
View raw message