From dev-return-10103-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Fri Jul 11 16:55:27 2003 Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 75719 invoked by uid 500); 11 Jul 2003 16:55: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 Delivered-To: moderator for dev@apr.apache.org Received: (qmail 36787 invoked from network); 11 Jul 2003 16:01:44 -0000 X-Authentication-Warning: onyx.ispol.com: grisha owned process doing -bs Date: Fri, 11 Jul 2003 12:01:45 -0400 (EDT) From: "Gregory (Grisha) Trubetskoy" X-X-Sender: grisha@onyx.ispol.com To: dev@apr.apache.org Subject: Getting a hash table into shared memory In-Reply-To: <20030711091149.GA31816@redhat.com> Message-ID: <20030711113810.B72044@onyx.ispol.com> References: <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 Hi - I'm in search of some wisdom here. I am looking at ways to have a hashtable into shared memory. This is for mod_python, so maximum reliance on APR and least replication of effort is a requirement. I have seen a couple of examples in httpd code - mod_ssl and mod_auth_ldap can use shared memory for caching their internal data. Both of those use their own hash table implementation. Actually mod_ssl uses a hash table by Gray Watson (with its own license). The reasons are probably historical, but from looking at APR, it seems to me that it's not possible to use the APR hash table for this purpose. I'm hesitant to borrow from these examples because although they work, it seems there should be a more elegant way of doing this. Just to clarify, there are two possible ways to use shared memory. The first is when the shared memory segment is allocated prior to forking and its base address is reused by children, in which case addresses are all the same and there is no need to deal with offsets. The only requirement is that a different malloc-like functions are used (both mod_ssl and auth_ldap use wrappers around APR rmm funcs). 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... In any event, I'd appreciate some pointers or suggestions. Is it possible for example to somehow create a pool that would use rmm_alloc functions? Grisha