Date: Thu, 26 Aug 1999 11:20:20 -0400 (EDT)
From: Ryan Bloom <rbb@raleigh.ibm.com>
To: new-httpd@apache.org
Subject: Re: First in a long line of APR related patches.
In-Reply-To: <Pine.LNX.3.96dg4.990824010713.32043N-100000@twinlark.arctic.org>
Message-ID: 
 <Pine.LNX.4.04.9908261100080.18364-100000@chosondo.raleigh.ibm.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org


BTW, one of the places that the context is nicer than the pool, IMHO, is
the abstraction.  This lets me do multiple things that IMO are harder to
do with just pools.

We have already had one person ask for APR without the requirement of
having to pass pools around.  How do we do that without relying on
malloc/free, which has also been discouraged?

Dean, has suggested possibly changing the way pools work, to treat memory
just like any other pool-ed resource.  (Hanging it off a clean-up).

Plus, we have Ralf's mm-pools, which use pools in shared memory.

Not to mention, the possibility of having a memory-management scheme like
pools, only with the ability to shrink as well as grow.

If we have to pass pools around, this abstraction is hard to acheive.  If
we pass around contexts, with one field being a "pool"-like structure,
this is easy.  On a non-pool'ed system, that field is either always NULL,
or just not there, on any other system, where memory management is handled
by apr functions, that field is wahtever structure makes sense.

I envision something like this (in the not-so-distant future)

typedef ap_context_t {
#if USE_POOLS
    /* Standard Apache 1.3 pools */
    ap_pool_t *pool;
#elif USE_SHRINK_POOL
    /* Pools that can shrink */
    ap_shrink_pool_t *pool;
#elif USE_FOOBAR
    /* Some new memory manager we haven't discussed yet.
    ap_foobar_t *pool;
#else
    /* Use malloc/free, and put nothing there. */
#endif
    void *user_data;
} ap_context_t;

This lets me write any program using any memory manager, and have it
choose which memory manager scheme to use during compile time.  Yes, this
can be done with typedefs, but I really think this is easier to debug.
Plus, this gives us the user data stuff.

Do I have a compelling need for user data?  Yes and no.  I like the idea
of putting the user data in a single location for all of the Apache
structures.  But it isn't really necessary.

It has been requested, and no, I don't remember who wanted it, that all
APR types have a place for user data.  This makes sense to me.  It allows
people to attach data to any apr structure when it is created, and know
that data will go away when the strcuture goes away.  Putting the
user-data in the context, which all APR types have, seems like the best
way to implement this.  But, that is of course, MHO.

Ryan

_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.