I may be wrong, but the only signifficant difference (in wall clock time of blocking squid) between checking configuration and applying it are the external helpers (external_acl, auth helpers, piped loggers).
Getting configuration data from the network could be a nice thing on the other hand, but external_acl provide the means for doing something similar. Rather than providing a 'slow migration' for every configuration directive, making 'slow migration' for 'expensive' directives (like external_acl, auth helpers, etc.) would have the same result but with less work, right? Regards, On 4/25/06, Robert Collins <[EMAIL PROTECTED]> wrote: > This is just a long term thought: should we make config parsing non > blocking. > > This would allow reconfiguration to on a running system with less > disruption than it has now, but... > > would require that all the configuration data be much more dynamic than > it is now - for instance the closure of listening ports, conversion of a > port that is currently listening as http to listen as https etc. > > The nice thing about this is that we could configure up a new > configuration that is not 'active', make sure its all koscher and so > forth, then let it slide into place by a pivot-like process - change the > callbacks for all the listening ports, and update any other global > variables - but not removing the prior config - and then let the old > config free as references to it die. > > This isn't very tied into async/sync behaviour, but making it explicitly > async would allow for parsing very big configs, or geting configuration > data from over the network etc. > > Rob > -- > GPG key available at: <http://www.robertcollins.net/keys.txt>. > > -- Gonzalo A. Arana