Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 80697 invoked by uid 500); 15 Nov 2001 16:34:22 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 80686 invoked from network); 15 Nov 2001 16:34:21 -0000 Date: Thu, 15 Nov 2001 08:34:18 -0800 From: Justin Erenkrantz To: dev@httpd.apache.org Subject: Re: 2_0_28 tarballs rolled and available Message-ID: <20011115083417.B855@ebuilt.com> Mail-Followup-To: Justin Erenkrantz , dev@httpd.apache.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Tue, Nov 13, 2001 at 12:27:48AM -0800, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: > -----Original Message----- > From: Aaron Bannert [mailto:aaron@clove.org] > >I think Justin is going in the other direction -- your proposed changes > >need to be broken down into finer grained proposals/functionality. > > I don't think I quite got it - I'll probably wait and see what he means by > "a new APR API for accessing shmem that treats it as a fixed-length > hash/DBM".. I'd be willing to help if required. Sorry for not replying sooner. I hurt my shoulder yesterday, so I can barely raise my head - let alone use a computer. It's a little better - enough that I can type this out, but not much more. So, any code from me will have to wait until my shoulder gets better (weekend?). Anyway, the problem that I have in your patch was that we introduce dynamic memory allocation on top of the shmem. It is an immensely complicated piece of code, so I'd like to see if we can avoid having to add it just for mod_ssl. So, my idea in short: - Allocate a shmem DBM - giving it the number of elements you want to store and the max size of each element you want to store. This will return some dbm (we *may* be able to integrate it with gstein's recent work on factoring out DBM code) that APR allocated from shmem. You would do this in the parent before fork()ing off, so all children have access to this shmem region. - We must keep it fixed length in both key length and in data size. It must only store a char* (essentially a counted void*) because shmem doesn't allow pointers in its data sets. This *should* be sufficient for mod_ssl? All you want to do is keep the session private key (or similar), right? It is a static buffer with a fixed size. Rough functions (ignore the names): - apr_shmem_dbm_create(size_t maxelems, size_t maxklen, size_t maxvlen) - apr_shmem_dbm_put(char* key, size_t klen, char *val, size_t vlen) - apr_shmem_dbm_get(char* key, size_t klen, char **val, size_t *vlen) - apr_shmem_dbm_iterate() - apr_shmem_dbm_next() - blah, blah, blah > I do share your concerns regarding the overhead.. But, I still feel that > freelist management should be a part of any shared memory management. If > there's no such policy, then we should just not coin the word *management* - > because there's no management being done here. shmem == shared memory. We never said shared memory management. =) How does this sound? -- justin