You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ryan Bloom <rb...@raleigh.ibm.com> on 1999/05/13 15:07:20 UTC
Pools in apr types.
Okay, I am re-opening this can of worms. My understanding of how things
were left about contexts and other apr types is:
1) All apr types will have a pool pointer.
2) All apr types will have a pointer for user data.
3) All apr functions will be passed a context type.
That means the pool allocation prototype becomes
ap_palloc(ap_context *, ap_ssize_t);
This is fine, but why then are we putting a pool pointer into each apr
type? It makes more sense to put a context pointer in every type. I
tried to make the change to the ap_ functions moved down from Apache, and
having a pool pointer in every type just doesn't work very well.
So, I would like to change point 1 to be:
All apr types have a context pointer.
Thoughts/Objections.
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.
Re: Pools in apr types.
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
yOn 14 May 1999, Ben Hyde wrote:
> Rodent of Unusual Size <Ke...@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
data.
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
currently.
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
or
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
_______________________________________________________________________
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.
Re: Pools in apr types.
Posted by Ben Hyde <bh...@pobox.com>.
Rodent of Unusual Size <Ke...@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.
The user data field is not the issue. I find your reply
bewildering since it seem to ignore my issue "unnecessary
incompatiblities"
- ben
Re: Pools in apr types.
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Dean Gaudet wrote:
>
> On Fri, 14 May 1999, Rodent of Unusual Size wrote:
>
> > No, thank you. IMO, a pool is a primitive data structure,
> > and shouldn't have a user-data field in it.
>
> How do you explain cleanups?
They're attributes of pool operation, not arbitrary and
probably unrelated data.
--
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>
Re: Pools in apr types.
Posted by Dean Gaudet <dg...@arctic.org>.
On Fri, 14 May 1999, Rodent of Unusual Size wrote:
> No, thank you. IMO, a pool is a primitive data structure,
> and shouldn't have a user-data field in it.
How do you explain cleanups?
Dean
Re: Pools in apr types.
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Ben Hyde wrote:
>
> Rodent of Unusual Size <Ke...@Golux.Com> writes:
>
> > How about:
> >
> > 1) All APR types will have a context pointer.
> > 2) The context type will have a pointer for user data.
> > 3) All APR types will have a pointer for user data.
> > 4) All APR functions will be passed a pointer to either an
> > APR type or a context.
>
> That's good.
Phew!
> 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.
--
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>
Re: Pools in apr types.
Posted by Dean Gaudet <dg...@arctic.org>.
I'm with Ben, I don't understand the need to introduce ap_context_t when
ap_pool_t would suffice perfectly and is already used in pretty much the
way the contexts want to be used. If a vote were taken I'd vote for
adding context stuff into ap_pool_t.
Dean
Re: Pools in apr types.
Posted by Ben Hyde <bh...@pobox.com>.
Rodent of Unusual Size <Ke...@Golux.Com> writes:
> How about:
>
> 1) All APR types will have a context pointer.
> 2) The context type will have a pointer for user data.
> 3) All APR types will have a pointer for user data.
> 4) All APR functions will be passed a pointer to either an
> APR type or a context.
That's good.
It is better than the design of the current server
because it allows the users to hang customization
off the data structures the APR API provides, and
because it works to assure that we don't neglect
to provide access to the resources provided by
the context in all routines.
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?
- ben
Re: Pools in apr types.
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Ben Hyde wrote:
>
> > 3) All apr functions will be passed a context type.
>
> I remain opposed to #3. It is, and remains, a waste of
> cycles. Possibly you'd be willing to change #3 to:
>
> 3) All apr functions should have direct or indirect access
> to a pool/context.
If we had O-O class inheritance in ANSI C, the APR types
would be descendants of the 'apr_context_t' class and
this would happen automatically. I don't know how to
reasonably accomplish the same thing in ANSI C, though.
How about:
1) All APR types will have a context pointer.
2) The context type will have a pointer for user data.
3) All APR types will have a pointer for user data.
4) All APR functions will be passed a pointer to either an
APR type or a context.
That way there's user storage available at the cross-object
context level, and at the specific-object level, both accessible
from the object itself (foo->userdata, get_userdata(foo->context)).
Unfortunately the access methods can't be named the same..
--
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>
Re: Pools in apr types.
Posted by Ben Hyde <bh...@pobox.com>.
Ryan Bloom <rb...@raleigh.ibm.com> writes:
> Okay, I am re-opening this can of worms.
I don't recall it closing.
> My understanding of how things
> were left about contexts and other apr types is:
>
> 1) All apr types will have a pool pointer.
> 2) All apr types will have a pointer for user data.
> 3) All apr functions will be passed a context type.
I remain opposed to #3. It is, and remains, a waste of
cycles. Possibly you'd be willing to change #3 to:
3) All apr functions should have direct or indirect access to a pool/context.
But, I will withdraw my veto and wander off and sulk.
> That means the pool allocation prototype becomes
>
> ap_palloc(ap_context *, ap_ssize_t);
This is a fine example of what I percieve as a valient attempt to
worship elegance over compatiblity. Why change the name to from
ap_pool to ap_context_t? It's new but is it worth the discontinuity.
> This is fine, but why then are we putting a pool pointer into each apr
> type? It makes more sense to put a context pointer in every type. I
> tried to make the change to the ap_ functions moved down from Apache, and
> having a pool pointer in every type just doesn't work very well.
>
> So, I would like to change point 1 to be:
>
> All apr types have a context pointer.
This is really about the operations you support on the root of your
type tree. I wouldn't put a resource pool in that set until my hand
was forced to do so. I can not count the times I've had to reenginer
systems with rich root types that were slow as a pig because every
little thing required filling out a dozen fields on allocation so that
creating instances was all your did with the cycles.
For example let's say we had a type symbol.
ap_symbol *ap_symbol_create(ap_namespace *ns, char *symbol_name);
I don't think it would have a pool, since I think the namespace
it resides in has one. The symbol lives inside the resource pool
of the namespace.
For example let's say we had a type ap_header,
ap_header *ap_header_create(ap_message *m, ap_symbol *name, char *text);
I don't think it would have a pool since I think the message has one
and the header's life cycle resides inside that of the message.
> Thoughts/Objections.
There is plenty of oportunity to make APR extremely interoperible with
the existing code. This has extremely high practical value. You
folks seem to be avoiding these for reasons I find esthetic rather than
practical.
Can we go back to exactly why we were frightened off thread locals?
was that fibers don't seem to support them. But fibers do support
a single item of state for each fiber. I'd be enthusastic about
our using that to provide a place for the "thread" to keep
local state.
- ben