On Fri, 7 Oct 2011, Christian Hägele wrote:

> In asyn-thread.c in init_resolve_thread there is a dummy_sock created (line
> 383). This dummy_sock is somehow used for the async DNS-resolve. But for
> some reason the CURLMPOT_SOCKETFUNCTION is also called with this socket,
> even though it has nothing to do with the transfers. It think that is wrong.

I think the explanation is given in the comment within init_resolve_thread():

   /* This socket is only to keep Curl_resolver_fdset() and select() happy;
    * should never become signalled for read since it's unbound but
    * Windows needs at least 1 socket in select().
    */

Does it really cause any harm?

> It is even more confusing when you are using the CURLOPT_OPENSOCKETFUNCTION
> and the CURLOPT_CLOSESOCKETFUNCTION and the CURLMPOT_SOCKETFUNCTION gets
> called with a (dummy-)socket never heard of.

Aren't all sockets libcurl informs it about "never heard of" until it tells
the app about them?

I think excluding this socket from that system might be more complicated than
including it, and since it won't ever have "traffic" it shouldn't be much of a
problem.

> In multi.c multi_getsock when the state is CURLM_STATE_WAITRESOLVE the
> dummy-sock is pulled out and added to the observed sockets, but this is not
> necessary when using a separate thread for async DNS-resolve (as described
> above on windows).

I think that's exactly what the comment about is about.

How important that comment and its effects are, is another matter. Did you try
just removing it to see what kind of impact you get on your application?

-- 
  / daniel.haxx.se

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