Stas Bekman wrote:
I'm trying to resolve two related items in todo/release:
The first step: provide support for read-only structure accessors, made all perl server_rec and process_rec accessors read-only (the patch is below).
I agree with most of this, save certain attributes of the server_rec below.
I don't think these should be writable, since it has the same effect as allowing 'cwd' in the multithreaded process, where one thread will affect another. All changes to the server_rec structures need to be done after the config and before the child_init phase.
in general, I don't agree with this - modifying several of the server_rec slots at request time is something that some (few) mp1 user required.
Did they wanted to affect the server for the future requests, or just the current request?
however, threaded environments continue to represent an endless shift in the way we typically think of doing things.
I think one solution that I offered at ApacheCon was to allow modification of server_rec slots and other server attributes under unthreaded mpms and read-only under threaded mpms. I still think this offers a happy medium between the two - if you require request-time modification of server attributes, either use prefork or rethink your requirements.
I don't find this a happy medium. An application/module developed on prefork mpm won't work on threaded mpm, e.g. cutting off windows users.
My definition of the happy medium is to provide the API that works indentically everywhere, and not create a burden for the developers to check their modules/apps on a bunch of platforms. It's possible that the threaded implementation will be slower, but it should work all the same from the user point of view. If the server_rec mods are required only for the current request, perhaps introducing a concept of localized server_rec is needed.
Also some server_rec records could be safely modified at the startup, so that's another reason for reviewing what should be r/o and what r/w. So startup and request time modifications are two different things, and should be each addressed separately.
So if Apache allows doing that and is not concerned about mutexing the modification of the server_admin field, then it's a bug in Apache and should be addressed by httpd-dev. If they provide the mutexing, we can then re-use it for mutexing r/w process/server accessors.
I don't recall any mutex code out there, and I suspect that their answer would be that modifying server attributes is not a supported use of the API and at your own risk. actually, even in mp1 this was true - if you set a server_rec slot at request time you were required to set it back at the end of the request or understand that the value would leak across requests if you didn't.
But doing:
$r->server->add_config('KeepAlive On');
at request time, is not forbidden by the API, no? Or is it only mod_perl which exposes add_config to users, and thus makes it easy to do unsafe things?
For records that we aren't sure about making r/w, we should make them read-only, since we can always re-enable that back after 2.0 API is frozen. It shouldn't affect anybody.
I think this needs to be sorted out before 2.0.
I was talking about structs we have no experience with. I thought we have agreed that won't be able to go through every possible method/accessors apache/apr provide and mark only those supported as a 2.0 API and the rest 'experimental'.
I was just suggesting that it's safe to turn all those 'experimental' accessors, read-only and then add the write access if we learn that it's needed, as it won't break any one's code.
+< port +< loglevel
I've required write access to these in the past
Sure, I can see the use for loglevel, but it should be local to the request, right?
What about the port? Can you give an example of why would you want to change it? Doesn't make much sense to me, since you are already listen'ing to port value. Unless you try to hop to another vhost.
+< keep_alive
I can see write access to this being useful
Examples?
<process_rec>
as I said above, I agree the process_rec should be off limits.
Thanks.
__________________________________________________________________ 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]
