> On 05 Jul 2001 09:14:03 -0700, Ian Holsman wrote: > > On 05 Jul 2001 08:46:05 -0700, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] -----------------------------------------------------------------------------
