We tried to make things safe and copy the string using perl's malloc, like in server_root_relative, which is slowing things down, but sort-of-OK when the string is short, and the API is not used heavily. But this copying can't be used in other APIs which potentially move mountains of data.
So it all comes to this - can we get rid of the pool argument completely and handle it behind the scenes? I think we can do that. This is still raw in my head but if we maintain a global variable (similar to Apache->request/Apache->server), switching to the right pool (pconf at the startup, server pool at child_init/exit, connection pool for filters and request pool for requests we may be able to completely get rid of it. If power users will want to use a specific pool (e.g. allocating memory from $s pool, while inside a request handler), they should be able to change the default pool via API and then restore it back (e.g. $old_pool=Apache->default_pool($new_pool)).
The question are whether 1) it's a good idea 2) it's not going to hurt the performance (remember Apache->request is bad under threads because it uses Thread Local Storage, which is supposedly slow).
Also maybe if we assume that there are never too many connections with KeepAlive, we could always use $c->pool and never $r->pool, which will simplify things a lot, with a bit of memory overhead (but re-usable). Since most setups don't use KeepAlive with mod_perl it may just work.
Againg these are just raw ideas. So please throw yours in and let's cook some nice meal.
__________________________________________________________________ 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]
