>> Instead I want to introduce:
>>
>> ares_dup_channel() that instead can make a new channel and clone the
>> config used from an existing channel. It will then clone all config
>> options, including future new things we add.
>
> I simply call it ares_dup() now. See attachment for my work in progress.
> If nobody objects, I'll commit this in a day or two and then proceed
> with the
> ares_set_socket_callback patch and start preparing for a release.
>
> I want to name the next version 1.6.0 due to the "new way" this new API
> style signifies.
I'd prefer not to have ares_save_options() deprecated. I'm actually
using it to cache the config outside of any connection context as I
can't guarantee there is a connection context available at that point.
I guess I could keep a connection context around that will _never_
be used, but that seems a little more wasteful.
The point is to not have to go to disk in order to read stuff like
/etc/resolv.conf, or on Windows, have to make potentially expensive
calls to get DNS server configs (which includes a LoadLibrary()
call!).
My current code has a cache timeout so it _will_ reload the latest
OS-provided settings every few minutes to try to stay in sync with
the system. Obviously, for low-volume systems, the config loading
overhead is meaningless, but when you can potentially have a few
thousand connections a minute (with each thread having its own
c-ares connection context), it starts to make a difference.
-Brad
Received on 2008-12-02