On Fri, 7 Aug 2009, Constantine Sapuntzakis wrote:

> Under Windows XP SP3, my app spins when using threaded async name resolution
> with curl_multi. The dummy socket allocated in the threaded resolver
> (hostthre.c) is always selectable for writing, so select always returns
> instantly.

Strange. It does this _always_ ? I find it strange that nobody else has found
or reported this before then as the code has been like this for quite some
time now...

> The dummy socket was there because select() on Windows doesn't support being
> passed no descriptors.

Well, it was more strictly a way to prevent the app from having to
special-case the name resolver period. However, apps already need to do that
since during name resolving when the default sync resolver is used on *nix we
don't provide a "fake socket" so it gets maxfd -1 and select() on *nix
platforms don't like that...

> The patch below allows an app to indicate to curl that it does not require a
> dummy socket (CURLMOPT_NODUMMY). If the set of descriptors is empty then the
> app will call a sleep function (e.g. SleepEx) instead.

If it busy-loops with the socket, is there really any particular reason to
keep that broken code/behavior and only allow the nicer behavior with a new
option?

In other words: why not just rip out the dummy socket code?

> In addition, the patch implements polling for async resolv done starting at
> 1ms interval and decaying expontentially up to 250ms intervals. It retains
> the old behavior of not timing out name resolution.

That sounds... fair, assuming you can't make the resolver thread tell the main
thread instead.

The threaded resolver is KNOWN_BUG #64 already of course, so I'm a bit afraid
that touching it will make it break even more.

> P.S. I considered an approach of using WSAWaitForMultipleEvents instead off
> select and having the async name resolver call a user-defined callback that
> woul do a QueueUserApc on the waiting thread to wake up the
> WSAWaitForMultipleEvents when the name resolution was done. This has the
> advantage of not polling but the disadvantage of requiring W2K or above and
> rewriting my select-based to code to use
> WSACreateEvent/WSAEventSelect/WSAWaitForMultipleEvents.

But XP is after W2K, right? Maybe that requirement isn't that bad if it makes
the code better? And also, can't the code be made #ifdef'ed on the correct
version so that you could still build with the old approach on older windows?

> I also considered using ARES but my app requires religiously following the
> Windows DNS suffix rules for non-FQDN names.

Ah. We'd of course like c-ares to work as a proper replacement so we would
like to have those things work in c-ares as well. Although of course "someone"
needs to do the job... :-O

-- 
  / daniel.haxx.se