From dev-return-10106-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Fri Jul 11 19:12:02 2003 Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 33646 invoked by uid 500); 11 Jul 2003 19:12:01 -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 33611 invoked from network); 11 Jul 2003 19:12:01 -0000 Errors-To: Message-Id: <5.2.0.9.2.20030711135845.03e7a658@pop3.rowe-clan.net> X-Sender: wrowe%rowe-clan.net@pop3.rowe-clan.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 11 Jul 2003 14:00:05 -0500 To: "Gregory (Grisha) Trubetskoy" From: "William A. Rowe, Jr." Subject: Re: Getting a hash table into shared memory Cc: dev@apr.apache.org In-Reply-To: <20030711113810.B72044@onyx.ispol.com> References: <20030711091149.GA31816@redhat.com> <20030711091149.GA31816@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N At 11:01 AM 7/11/2003, Gregory (Grisha) Trubetskoy wrote: >Just to clarify, there are two possible ways to use shared memory. >... >The second is when a (child) process would be able to allocate a shared >memory segment and others could attach to it. This, of course is a lot >more complicated, because now the base address may differ from process to >process and the table needs to deal with offsets. Both examples mentioned >above do it the first way, and for my pusposes it would be acceptable, >though the second would be fantastic... Notice the apr_rmm API, it was designed entirely for this purpose, where memory is described in size and relative position, not in absolute addresses. It won't address your entire hashtable requirements, but it is a start to your memory addressing issues. Bill