Daniel Stenberg wrote:
> However, this fix of yours blindly assumes that there is a pending ares
> request for this connect data that we should cancel. When the multi
> interface is used, the same ares 'channel' is used for name resolves for
> all easy handles so this can most probably mistakenly cancel a name
> resolve request for another handle if you have a bad day.

Ouch!

> I think we need to make sure that we only cancel actual callbacks for
> this particular connect struct... But there's no really good API for
> this in ares of today! I think we need to figure out and implement one.
>
> I'm open for (other) ideas on how this could be done.

As I said earlier, I'm not very familiar with ares and have only been
poking at it a little bit over the last couple of days. However, if you
could outline a little bit what such an API would look like, then maybe
I could try and take a shot at implementing it.

In the meantime, would the best short-term option for me be to switch to
using the threaded resolver?

Thanks,

Harshal
Received on 2005-08-04