...are more painful to deal with than you might think, if the user is allowed to code them in any order.
I'd like the comparisons between MaxClients and ServerLimit and the equivalent thread directives to be coding order insensitive. So I created a post-config hook to do the comparing & adjusting. The code was very simple, but the log messages went to the error log file twice, rather than to the console once which is what people are accustomed to for config errors. worker already has the same situation with MaxClients and ThreadsPerChild. It has a clever but kind of scary solution: a pre-config hook which swaps nodes in the config tree if it doesn't like the order. Then the comparisons, adjusting, and logging are done when the second directive is parsed. While I think it's a very cool hack, mucking with the innards of the config tree bothers me some. config.c could provide an API to do order checking and swapping, but I can't see this as a general solution. Think about cases where one directive is in container X and the other isn't - yuck! What if the very first ap_run_post_config hook was moved to before the logs files were opened? Then we could have simple logic to compare or otherwise process multiple directives. Any error messages would go directly to the console. If you wanted them to also go to the error log file, that would just happen during the second post-config call; if you don't want that, it's easy to avoid. Thoughts? Greg
