httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <rpl...@apache.org>
Subject Re: Caching the useful headers
Date Sat, 09 Feb 2008 19:49:15 GMT


On 02/09/2008 08:39 PM, Dirk-Willem van Gulik wrote:
> On Sat, 9 Feb 2008, Ruediger Pluem wrote:
> 
>>> +    return apr_table_make(pool, 10);
>>> +    };
>>> +
>> Why this? Just some type of defensive programming if someone feeds in a t == NULL?
>> If yes, I would prefer return NULL instead of creating an empty table.
>> Garbage in, garbage out :-).
> 
> That was my first approach as well. But then I noticed that the users of
> this functions virtually always will have to serialize/store the tables;
> or otherwise track them. So if we have 3 options -
> 
> -	if (r->headers_in)
> 		in = ap_cache_cacheable_hdrs_in(
> 		serialize(in)
> 	else
> 		mark a skip or something that you did not
> 
> -	headers_in = ap_cache_cacheable_hdrs_in(
> 	if (headers_in)
> 		serialize(in)
> 	else
> 		mark a skip etc
> 
> -	headers_in = ap_cache_cacheable_hdrs_in
> 	serialize(headers_in) which can deal with empty arrays
> 
> or we defer - and simply return null and have the respective serializes
> all deal with this. The advantage of returning null is that it is quicker
> to check for those serializers. But if I had to optimize - I'd rather do
> so on assuming an array - as in reality we have the headers virtually
> always ?

This is my thought. I currently see no situation where we supply a NULL
to ap_cache_cacheable_hdrs now or in the future (in most cases I would assume
not even an empty table). So I think returning NULL in ap_cache_cacheable_hdrs
in this situation and write the serializer in a way that it can handle a NULL
table gracefully seems to be a quick and sufficient measure here to avoid segfaults.
So I would vote for option 3.

Regards

RĂ¼diger


Mime
View raw message