Stas Bekman wrote:
As some of you may have followed the discussions here, we are scared to
death from users using the wrong pools and shooting themselves into the
foot.
well, some are more scared than others ;)
we will see
Really, what happens is that we take the cool easy Perl and bring back the malloc/free issue in a different reincarnation. It's the 'free' part that is going to bite us, because memory can be freed w/o a user knowing about it, if they have used the wrong pool.
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)).
fwiw, I'm not crazy about this idea at all. I like the idea that mod_perl simply exposes the Apache API, pools and all, and don't really want to see that changed.
really, I see this as an education issue for users - they need to learn the lifetime of various activities and choose a pool appropriately. sure, they will leak memory if they use pconf from within a request, but that's a tuning issue - it doesn't mean that we ought to alter the API to the point where we make the decision for them.
as for pool going out of scope before the perl data does, well... I guess that can be more problematic than just leaking memory. but again, I think users need to understand how to match the proper pool with their activity.
I can understand you wanting to keep users from being able to shoot themselves in the foot. however, this is a very complex application we're working on - if they don't understand how things work, they'll shoot themselves no matter what we do, since we can't protect against everything. I had a user in a talk ask me what happens if they register a child-exit handler with $r in a closure...
Geoff, I think you are taking this idea of matching the C API a bit too far away. If the C API was simple people would have used C to write their handlers in first place. But making the perl API match C 1:1 you make the perl API hard to use, and requires a steep learning curve. This may as well kill mod_perl for massive mid layer of users, and leave those running registry and not using the mod_perl API and those who know the inside-outs of mod_perl.
IMHO, passing pools around is a totally unnecessary confusing and error prone feature that if we can avoid, user will thank us for it.
One example of error-proneness is when users cat-n-paste a piece of code from some startup example:
whatever($s->pool, ...)
into their request handler. Most likely they won't notice that they need to s/$s->pool/$r->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).
$r->pool is a subpool of $c->pool, so I doubt it matters much.
Since most setups don't use KeepAlive with mod_perl it may just work.you'd probably be surprised.
I certainly could. I haven't been using mp by myself in production for too long. That's not good. I hope to change that situation, once 2.0 is released.
really, I'd rather concentrate on making sure the underlying hooks are solid before we go with some kind of premature-optimization-like protection scheme. if you're really, really worried about this, we could offer some kind of meta-method that retrieves the appropriate pool for the phase. for instance,
my $pool = Apache->proper_pool;
which would return $r->pool during a request, $s->pool for the appropriate vhost as config time, etc. that's certainly simpler, and it gives knowing users the option of foregoing processing when they are confident in their pool selection abilities.
If you do all the work to provide that API (which is not trivial at all, besides being potentially expensive), you already have a default pool (exactly as I've suggested), so you don't need to pass it to the functions and make things obscure.
__________________________________________________________________ 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]
