apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: [PATCH/CONTRIB] Shared Mem Hash Table
Date Thu, 05 Jul 2001 16:27:28 GMT

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

You can handle that with offsets.  All of that should be hidden behind the
SMS interface.  If it isn't, then the SMS interface is broken.

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

Everything in Computer Science can be done with one more level of
indirection.  :-)

Ryan

_____________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
Covalent Technologies			rbb@covalent.net
-----------------------------------------------------------------------------


Mime
View raw message