On Sun, 29 Apr 2012, Daniel Stenberg wrote:

> That is not true. I would expect us to have gotten (many more) bug reports if
> it just didn't work with the easy interface.

Inside this function, Curl_resolver_is_resolved, after we determined
the resolving hasn't finished, and calculated the timeout value, we
call

if(done) {
}
else {
  ...
  Curl_expire(conn->data, td->poll_interval);
}

There is this check in the beginning of Curl_expire:

  if(!multi)
    return;

So I guess Curl_expire doesn't do anything if not used in multi interface (?)

> The resolver is not directly used at all by an application. The application
> uses libcurl's API as documented and libcurl will do the proper name resolves
> in the backend. The API is independent of what resolver backend that is used.

This is exactly what I expected, but it turns out
curl_multi_remove_handle() calls

Curl_done(&easy->easy_conn, easy->result, premature);

which, in turn, calls

Curl_resolver_cancel(conn);

and then

destroy_async_data(&conn->async);

and finally blocks at here:

Curl_thread_join(&td->thread_hnd);

> Now, is curl_multi_remove_handle() can hang due to this, it is either a bug
> that can be fixed, or it is due to a more fundamental problem in that
> something needs to wait for the thread to die and the name resolve thread
> cannot easily be terminated without risking to lose resources.

I guess it's totally understandable that a 'join' would block here,
for the whole need for a threaded resolver is because the system
resolver blocks. If we can have only one name resolver thread for each
connection (is that so?), we're bound to wait for that thread to
finish before we can use name resolver again. If we can have multiple
threads and 'detach' them, we can potentially have multiple (blocked)
resolver threads running while the main system continues.

Regards,
Mac

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2012-05-01