Re: Apache using apr.

[Dean Gaudet <dg...@arctic.org>]

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...

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. 

Dean

Re: Apache using apr.

[Dean Gaudet <dg...@arctic.org>]

On Wed, 8 Sep 1999, Greg Stein wrote:

> 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.

i mean the allocator would use the void * provided by the context, the
allocator needs somewhere to hang its private data.

> 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.

private. 

Dean

Re: Apache using apr.

[Greg Stein <gs...@lyra.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/