Message-ID: <37D646A3.65AA1ED9@lyra.org>
Date: Wed, 08 Sep 1999 04:21:07 -0700
From: Greg Stein <gstein@lyra.org>
MIME-Version: 1.0
To: new-httpd@apache.org
Subject: Re: Apache using apr.
References: <Pine.LNX.3.96dg4.990907160223.2888e-100000@twinlark.arctic.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

Dean Gaudet wrote:
> 
> On Fri, 27 Aug 1999, Greg Stein wrote:
> 
> > We should use contexts so that the user data can be carried around. Dean
> > suggested added a void* to the pool structure. That is a bit silly as
> > that means pools are no longer just memory handling types, but include
> > other stuff. The best label to apply for that case is "context".
> 
> note if you see my other post about supporting all types of allocation
> within one pool you'll see that it'd be cool for the different allocators
> to have a void * that they can allocate within the pool...

I'm not sure that I follow what you're getting at here. Would the
allocator use the void* internally? Well, sure... that makes sense. I
would expect them to have some kind of private storage in there.

Or do you mean something about exposing the void* to users? In that
case, then you're monkeying up the abstraction between allocators and
context storage.

> and as far as usage for the void *, we need some sort of unique identifier
> for each user of the pool.  ken suggested the module number method, but of
> course that doesn't work within APR, because modules are an apache thing.

atoms.

At a minimum, that damn "table" type really has to change. The "values
are strings" thing is just a horrendous pain. I want a name => void*
mapping. Hell, I want binary-blob => void* mappings. Where are those
Python dictionaries when you need 'em? :-)

Cheers,
-g

--
Greg Stein, http://www.lyra.org/