Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 31661 invoked by uid 500); 5 Jul 2001 13:00:26 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 31632 invoked from network); 5 Jul 2001 13:00:23 -0000 Message-ID: <002601c10553$739a48c0$04000100@sashimi> From: "Bill Stoddard" To: "APR Development List" References: <3B43E69F.4010001@cnet.com> Subject: Re: [PATCH/CONTRIB] Shared Mem Hash Table Date: Thu, 5 Jul 2001 09:07:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N > 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) To the best of my knowledge, you cannot expand a shared memory segment (after fork) and ensure that all processes use the exact same addresses to access that memory. If one of your processes increases the size of the hash table, you have forever screwed up the hash table for all the other processes because you now have addresses in the table that may point to completely different storage in all the other processes. Bill