httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Hyde <bh...@pobox.com>
Subject Re: Pools in apr types.
Date Thu, 13 May 1999 15:26:42 GMT
Ryan Bloom <rbb@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

Mime
View raw message