Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 76226 invoked from network); 13 May 2009 16:22:22 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 13 May 2009 16:22:22 -0000 Received: (qmail 64209 invoked by uid 500); 13 May 2009 16:22:21 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 64146 invoked by uid 500); 13 May 2009 16:22:20 -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: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 64137 invoked by uid 99); 13 May 2009 16:22:20 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 May 2009 16:22:20 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: 76.96.30.40 is neither permitted nor denied by domain of jim@jagunet.com) Received: from [76.96.30.40] (HELO QMTA04.emeryville.ca.mail.comcast.net) (76.96.30.40) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 May 2009 16:22:10 +0000 Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id qznS1b00A16AWCUA44Mr47; Wed, 13 May 2009 16:21:51 +0000 Received: from [192.168.199.10] ([69.251.84.64]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id r4Mp1b00L1PGofZ8S4MqfX; Wed, 13 May 2009 16:21:51 +0000 Message-Id: From: Jim Jagielski To: dev@httpd.apache.org In-Reply-To: <4A0AEED7.10705@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: ap_slotmem Date: Wed, 13 May 2009 12:21:48 -0400 References: <513291A5-827A-4830-855D-7F60D967E805@jaguNET.com> <4A0AD673.7010107@gmail.com> <8BBDA089-FAF1-4628-905E-B0E974E16A93@jaguNET.com> <4A0AEED7.10705@gmail.com> X-Mailer: Apple Mail (2.935.3) X-Virus-Checked: Checked by ClamAV on apache.org On May 13, 2009, at 12:01 PM, jean-frederic clere wrote: > Jim Jagielski wrote: >> On May 13, 2009, at 10:17 AM, jean-frederic clere wrote: >>> Jim Jagielski wrote: >>>> OK, I think having 2 more API functions rounds out the impl; >>>> Consider: the current assumption is that the user manages the >>>> indexes into the slotmem. But what if the user doesn't? >>> >>> Then he can't use the stuff :-( >>> >>>> Certainly >>>> it would make sense for the slotmem to know what slots are now >>>> currently available and return a "free" slot to the caller. >>>> So I think a "grab" and a "return" function are required as well. >>> >>> I have malloc() / free() / getused() / getfree() switchable logic >>> that I can add quickly. Basically it create a table of used and >>> free slotmem additionally to data it. >>> >> *grin* >> Yesterday I added in a 'inuse' table, > > With a int * instead a char * we could have a kind of next free to > have a fast grab(alloc). > My impl was just a flag table to determine if the slot was used or not (and hence 1 or 0). If we can overload this for other goodness, then +1. I am thinking also 2 other things: 1. We should prevent a get or put if the slot has never been grabbed (alloc'ed). 2. We should get rid of the ap_slotmem_mem() function... The user should never need to know the pointer to the dataset; all access should be via the slot number and slot name.