The problem that bothers me is the pool. Since now we have $s->server_root_relative, it's almost as bad as using a global pool if users will happen to use it in requests, because it'll leak memory untill the server is killed. And users will use it, just because they can.
Moreover we do this silly (but necessary) protection and copy the whole string into a perl sv, scared that someone will use a short-lived pool object when allocating this variable (was my idea).
I say, let's drop that glue and write it in pure perl:
use File::Spec qw(catfile);
sub Apache::Server::server_root_relative {
return catfile Apache::server_root, @_;
}well, may be check that the thing exists like the apr_filepath_merge does. I haven't benchmarked it. But I won't be surprised if the performance/memory usage combination won't be better than the C equivalent (remember that at the moment we allocate the string twice, because of the copy). And we totally eliminate "the pool syndrom".
It'd be a good idea to look at other APIs that require a pool object.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
