httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <>
Subject Re: Pools in apr types.
Date Sat, 15 May 1999 07:09:51 GMT
yOn 14 May 1999, Ben Hyde wrote:

> Rodent of Unusual Size <Ken.Coar@Golux.Com> writes:
> > Ben Hyde wrote:
> ...
> > > Now if we change the name context to pool your
> > > back to the nice workable design used in the current
> > > server and you have avoided creating any unnecessary
> > > incompatiblities.  Please?
> > 
> > No, thank you.  IMO, a pool is a primitive data structure,
> > and shouldn't have a user-data field in it.
> Pants on fire?  You just said that all apr types will
> have a user-data field.

With the current proposal, pools would not be an exposed apr data type,
so they wouldn't be included in the "all apr types".  IMHO "all apr types"
should only include those being exposed to the user.  Otherwise, some apr
types will get multiple areas for user data.  For example:

apr_dir {
   apr_pool {
      user-data area;
   OS dir strucutre
   user-data area;
   apr_direntry {
      user-data aread;

The apr_direntry is not exposed to the user at all.  Which user-data area
does the user use in this case?  If we don't expose pools, and "all apr
types" refers to exposed types only, this problem goes away. 

> The user data field is not the issue.  I find your reply
> bewildering since it seem to ignore my issue "unnecessary
> incompatiblities"

Yes, there are incompatibilities in this new model.  I do not believe
they are unnecessary, not that they are too much for module writers to
handle.  The context area allows us to do some interesting things.  First
of all, if all apr types should have user-defined data.  And each apr type
has a context pointer, then we only need one API to get at user-defined

If we garauntee each apr type will have a context, we can expose that
field to the users, and take advantage of that fact.  For example:

ap_dir_t mydir;
mydir = ap_opendir("foo");
ap_set_user_data(my-dir->cntxt, my_data);

Without the context type each new apr type needs a new set of functions to
define/access their user data.

ap_dir_t mydir;
mydir = ap_opendir("foo");
ap_dir_set_user_data(my-dir, my_data);

One of my problems with putting this stuff into pools, is that right now
pools are fast, tight data structures.  I don't want to put everything
inside of pools.  This goes against my view of readable code.  If we put
everything inside the pool type, we make in next to impossible for anybody
to maintain the pool code unless they were around to see it develop.  In
my opinion, this severly limits the life-time of pools.

Now, having said all of that.  I don't really care what we call this new
type.  You want to change the current name of the pool type to
ap_internal_pool and call this new thing an ap_pool_t, fine.  That doesn't
bother me at all.  You want to leave pools alone and call the new thing
ap_context_t, fine.  Please note however, that keeping the type a pool
type will require users to change their code, because we said originally
that all apr types would begin with "ap_" and end in "_t" and pools don't

If all we are arguing about is what to call the thing, but we all agree on
what needs to go where (I think we do, but I was without e-mail all day
yesterday, and it is just now starting to trickle in), then lets realize
that no matter what we call it, our users need to change their code.  And
no matter what we call it, we can provide an EASY method for them to do
it.  Either:

s/pool \*/ap_pool_t \*/g
s/pool \*/ap_context_t \*/g

Neither is hard to do.  I personally think, the second is a LOT less
confusing for long time module writers, because it doesn't contaminate the
concept of a pool that they are so used to.


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

View raw message