On Wed, 11 Jun 2008, Christopher Palow wrote:

> Cool. Let me reproduce the timeout case and see if there really is a race
> there or not (I agree there isn¹t one in the c-ares lookup case). It all
> depends on when the close() happens with respect to curl_multi_socket*()
> returns. As long as applications don¹t create new sockets off the callbacks
> (socket change, read, etc) I think we¹re ok. Maybe it should be documented
> that apps shouldn¹t make new sockets off callbacks and instead queue them to
> be done in the event loop. I¹ll try and get back to you later today.

While I (finally) understood why we need to alert the app when a socket has
been closed even though the same one gets re-used, I cannot see this race case
you mention.

So what if the app creates a new socket or file descriptor in the callback,
how would that hurt libcurl?

-- 
  / daniel.haxx.se