Hi -- > Some time ago, I proposed this large patchset (better described, > I think, by the message referenced by the second link below): > > http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=114729206702495&w=2 > http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=114788040600327&w=2 > > Discussing the issues on IRC, I received a few responses, including > a long one from William A. Rowe, Jr. His main point, I believe, > was that the order of configuration directives in the tree should > never be altered from what it is in the configuration files. Therefore, > what the worker and event MPMs do now in their pre_config stages -- > namely, re-ordering ThreadsPerChild ahead of MaxClients -- should not > be done. Instead, all such order-dependent configuration directive > checking should be done in a post-config phase, either open_logs or > post_config.
Well, as promised (threatened?), here are a complete set of patches, I believe: http://people.apache.org/~chrisd/patches/httpd_mpm_configs/ I thought I'd wait a few days and see if objections were raised, then commit at least the prefork, worker, and event MPM ones, which I've tested quite extensively. The patches for the other four platforms (winnt, netware, beos, and mpmt_os2) I have no way of testing. If anyone with access to one or more of those platforms could test and review, that would be greatly appreciated! Of those, the Windows one is the one I'd particularly like someone to test and review. It has two key differences from the others: a) Like the prefork, worker, and event MPMs, there are ordering issues involved -- the bounds checks on ap_threads_per_child need to occur after the bounds checks on thread_limit. The existing code, I believe, has the same problem that exists with the worker and event MPMs: > [I]f ThreadsPerChild was not > specified at all, then the default value of DEFAULT_THREADS_PER_CHILD > could potentially be larger than the configured ThreadLimit, > and no test would be performed, since set_threads_per_child() > would never run. This could result in an out-of-bounds value > for ap_threads_per_child in the running server. b) Unlike the other MPMs, there seems to need to be some special handling with regard to what code runs in the parent. I've attempted to comprehend this without access to a test platform, but no doubt I've made some errors. So ... anyone for some testing? Anyone, anyone? Also ... objections to committing the patches for the prefork, worker, and event MPMs? Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
