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. 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. > process_rec > could be modified during the child_init phase, but I don't think > anybody will want to modify the process_rec struct at all. I don't think it's a good idea either. > 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. > 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. > +< port > +< loglevel I've required write access to these in the past > +< keep_alive I can see write access to this being useful > <process_rec> as I said above, I agree the process_rec should be off limits. --Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
