Am 28.12.2011, 13:39 Uhr, schrieb Christian Hägele
<haegele_at_teamviewer.com>:

>
> I think a similar approach for the dummy-socket in asyn-thread.c would
> be a better solution. That would make the code easier and the change-set
> smaller.
> The only reason for the dummy socket is to have one socket in the
> Curl_resolver_getsock() call. The better solution would be to work with
> the situation that Curl_resolver_getsock() returns no sockets. (Whichit
> does on non-windows platforms)
>

After I looked at the code again I see that it won't be easily possible to
get rid of the dummy-socket without breaking existing code. I tried to
just remove it on my windows-code and it works perfect, but that's because
I don't use the curl_multi_fdset-API (I use the CURLMOPT_SOCKETFUNCTION).
All the existing tests and example I saw so far assume that they won't get
a error from the select call after curl_multi_fdset. On windows the select-
call returns an error when called with empty FD-sets.

However, a downside of the current implementation is that this dummy-socket
is created in the DNS-resolve-function. So the code relies that
Curl_resolver_getsock will return at least one socket(on windows).
I think that's not a good approach. I would propose to move the creation
of the dummy socket to a '"on demand"-creation in the
curl_multi_fdset()-function.
This would still be an ugly workaround, but it won't rely on side effects
of
the DNS-resolve-implementation.

What do you think? My proposal is to move the dummy-socket in the
Curl_multi-
struct and create it on-demand (means on the irst call and only on windows)
in the curl_multi_fdset-function.

Regards,

Christian

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-12-28