> On Thursday 20 December 2001 12:22 pm, Greg Ames wrote: > > ...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! > > This is the point of the config tree, it allows you to modify the config before > we actually run the configuration, so that you can find these dependancies > and fix them quickly. Putting the logic in the directive handlers doesn't > really work, because you still have an order dependancy. > > Think of it this way, these are good configs: > > MaxClients 500 > ServerLimit 525 > > ServerLimit 20 > MaxClients 5 > > This is a bad config: > > MaxClients 525 > ServerLimit 500 > > Where do you catch it though? In ServerLimit, then you > will also catch the second good config above, which is a good config > If you try to catch it in MaxClients, you will catch the first config above, > which is a good config. > > The only solution is to choose default values that are invalid, so that you > can make sure that you always check in the last directive handler, but that > is incredibly ugly. We can easily create a function to do the swapping, > which is more generic, but the swapping is the only 100% correct way > to do this. > > Ryan
I'm inclined to agree with Ryan. Let's just make a function to do the swapping. Bill
