You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Torsten Förtsch <to...@gmx.net> on 2012/02/13 19:23:51 UTC

idea: faster pool user data

Hi,

I have just subscribed to the apr-list because http://apr.apache.org/mailing-
lists.html says:

<quote>
If you have patches or suggestions, feel free to share them with this list.
</quote>

For quite a time now I have this idea how a certain type of pool user data can 
be made faster.

It would require specialized pools. That means a request pool is still a pool 
but different from a connection pool or a process pool in httpd. For each type 
of pool we have a next_free_array_index integer variable. Further, there is an
API function to allocate such an index that simply increments the 
next_free_array_index per-pool-type variable and returns the previous value. 
Also, the type definition of an apr_pool_t is to be extented by an 
apr_array_header_t.

Now, at initialization time a user can allocate an index for a certain pool 
type. Then, when a pool of a certain type is created the an array of void* of 
length next_free_array_index for that pool type is created and initialized 
with NULL.

The user then can do with his own array slot what he wants.


My current need for something similar is as follows. Modperl allows Perl 
modules to create custom HTTPD configuration directives. Those directives then 
are merged at runtime with the server's base config. For this merge a Perl 
interpreter is needed which is found in a threaded environment by means of
r->server. But the merge function is passed only the request pool not the 
request_rec. So, for each request I store the request_rec as pool user data 
with the request pool. This solution works but is suboptimal because even if 
nothing modperl-related is used for the whole request I need to store the 
request_rec in the userdata hash because the merge may be the first operation 
that needs a perl interpreter.

With the new technique I could at init time in the parent httpd

static int my_req_pool_data;
...
my_req_pool_data=apr_pool_userdata_allocate_slot(AP_POOL_TYPE_REQ);

And then at runtime when the request is initialized:

*apr_pool_userdata_by_slot(r->pool, my_req_pool_data)=r;

To fetch the request_rec associated with the pool:

r=*apr_pool_userdata_by_slot(p, my_req_pool_data);

The apr_pool_userdata_by_slot operation is then basically an array lookup 
which is much cheaper than the hash lookup now.


Has something similar already been discussed? Is it worth thinking about?

Are there other options that I perhaps don't know about yet to achieve 
something similar?

Thanks for reading,
Torsten Förtsch

-- 
Need professional modperl support? Hire me! (http://foertsch.name)

Like fantasy? http://kabatinte.net