Subject: Re: Timeline for a new c-ares release

Re: Timeline for a new c-ares release

From: <daniel_at_poradnik-webmastera.com>
Date: Tue, 19 Jan 2016 12:28:02 +0100

Cytowanie Daniel Stenberg <daniel_at_haxx.se>:

> On Mon, 18 Jan 2016, daniel_at_poradnik-webmastera.com wrote:
>
>> Integration of epoll with c-ares is a bit problematic, because
>> current version misses some functionality.
>
> I'd agree that it is less than ideal, but as I've most likely said
> here before: I've built libcurl's event-based API and it can be made
> built to use c-ares and it works quite well.
>
> I'm sure I'm not alone when I say that we'll welcome improvements
> and patches!
>
>> And last thing are problems with timer for query timeouts, c-ares
>> does not allow to register callback for managing this timer. I did
>> this by updating timer every time after calling function which
>> initiates/terminates query (e.q. ares_query) and after calling
>> ares_process_fd. This works for me. However dedicated callback
>> should be more efficient, e.g. it could calculate timeout faster
>> than ares_timeout.
>
> I'm not sure we could make it much faster than ares_timeout, as
> that's exactly the logic that needs to be done. If there's a faster
> way, we should just implement that faster way in ares_timeout... Or
> am I missing something?
>
> If anyone is building applications where there's a lot of parallel
> queries within the same c-ares channel, ares_timeout of course gets
> fairly slow due to its linear search through them. That can
> certainly be improved.

I thought about small optimization here. First store time when timer
should expire somewhere. Then when new query is initiated, do not
restart timer if new expiry time it longer than stored one. Another
case is when response received over TCP is not complete and another
read will be required. There also may be other cases when timer does
not have to be modified, but this can be determined inside c-ares
library only, so callback is needed here.

One more thing come to my mind. I would like to see dedicated
functions to handle timeout and socket closed events. Calls
ares_process_fd(channel, ARES_SOCKET_BAD, ARES_SOCKET_BAD) and
ares_process_fd(channel, fd, ARES_SOCKET_BAD) works fine for me, but
at first it was not clear how to do this. Alternatively you can
clarify this in documentation, this also would be helpful.

-- 
Daniel
Received on 2016-01-19