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. Ryan _____________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] -----------------------------------------------------------------------------
