Daniel,

Thank you very much for your efforts and encouragement.

> On Wed, 31 Mar 2004, Roy Shan wrote:
>
>> I wrote up a dummy dns server which never responds to query. So I can
>> reproduce the timeout problem easily.
>
> Nice job! Did it turn out like anything you'd consider sharing that we
> could
> use to produce some test cases with to make it easier to test stuff like
> this?

The dummy dns server is a very simple python script. It's only 6 lines. :)
See the attachment.

>
>> if the dns server drops some query, select always returns 0. In that
>> case,
>> ares_process never gets called. Then, it never times out.
>>
>> My fix is: remove line 493. That is always calling ares_process after
>> select.
>
> You're a star! I take it this change makes my previously added timeout
> code
> for the ares lookup unnecessary?

I agree. We don't need to check timeout twice here. The timeout can be
determined by ares. The ares timeout rule is a bit complicated. Typical it
times-out within one minute. That sounds good enough for me.

>
>> 1. each handle has its own areschannel. Can the design be handles
>> sharing a
>> channel?
>
> Yes it can. We already have the share interface that allows data to be
> shared
> among curl handles and we could make the areschannel sharable using that.
> It
> is in fact mentioned in the docs/TODO document.

>
>> 2. Curl_wait_for_resolv blocks and waits. Can it become non-blocking?
>
> All occurances of Curl_wait_for_resolv() should be fixed to use
> non-blocking
> mechanisms indeed. At least if they can get called when the multi
> interface is
> used.
>
> It is however quite a heavy task to turn into reality.
>
> --
> Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
> Dedicated custom curl help for hire: http://haxx.se/curl.html
>