Re: proposal: make config parsing non-blocking.

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 <robertc@robertcollins.net> 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