httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject Re: Letting Table store non-char data
Date Thu, 23 Aug 2001 05:38:44 GMT
Greg Stein wrote:

>On Wed, Aug 22, 2001 at 03:59:56PM -0700, Ian Holsman wrote:
>
>>On Wed, 2001-08-22 at 15:41, Brian Pane wrote:
>>
>>>Ian Holsman wrote:
>>>
>>>>On Wed, 2001-08-22 at 14:12, Ryan Bloom wrote:
>>>>
>>>>>We had binary tables, but we removed them, because that is what hash
>>>>>tables are for.
>>>>>
>>>>agreed.
>>>>but there are no hash tables on the request rec structure.
>>>>
>
>Yes there is. apr_pool_userdata_set(..., r->pool)
>
>>>>My problem is that I have a module which implements a custom SSI tag and
>>>>a 'postfix' hook.
>>>>the postfix hook sets up the key based on the incoming request.
>>>>
>
>apr_pool_userdata_set("ian-ssi-tag-data", data, apr_pool_cleanup_null,
>                      r->pool);
>
>>>>when the SSI tag gets called (~10-50 per page) it needs to get the key 
>>>>the postfix hook had set up.
>>>>
>
>apr_pool_userdata_get(&data, "ian-ssi-tag-data", r->pool);
>
>>...
>>
>>>How about changing request_rec->notes to a hash table?  This would be
>>>a relatively simple change, as the notes field isn't used in a huge
>>>number of places in the standard modules.
>>>
>
>No need. IMO, r->notes should just go away. It is pointless nowadays.
>
Using the "userdata" functions on r->pool as a replacement for a
hash-based r->notes would be a mistake.  The interface to the userdata
in a pool is limited to "get" and "set" methods.  The API is missing
essential operations like "iterate over the set of elements in the userdata"
and "merge the userdata for a subrequest pool into the parent's r->pool."

--Brian



Mime
View raw message