On Wed, 14 Dec 2011, Christian Hägele wrote:

> IMHO that behavior can be worse than just surprising. Independent if libCurl
> calls the CURLOPT_CLOSESOCKETFUNCTION or closes the socket itself. If the
> CURLMOPT_SOCKETFUNCTION is called after closesocket it is possible that the
> same file-descriptor is already reused for another socket (or something
> else). Most of the time this shouldn't be a problem because normally only
> one thread works with the curl-multi-handle and the application shouldn't
> care if the file- descriptor is already invalid(or valid and pointing to
> something else). But either way it is always a bad thing to call a function
> with a 'dangling' file- descriptor. This might cause strange bugs is some
> place.

Yes indeed. It is important to remember and understand that it is the file
descriptor being given up by libcurl. By the time a REMOVE is sent on a file
descriptor, that file descriptor may in fact already have been closed (and
opened again by another thread or function within the application).

> Do you think that problem is serious enough to think about a change in the
> behavior(don't do anything with the socket after you called sclose).

I don't understand what you're suggesting. We don't do anything with the
socket after close! The only thing we do is to tell the application to forget
about it as we previously told it we used it.

Are you suggesting we don't call REMOVE on a socket that was closed?

> A patch for that problem is not easy because it changes some of the internal
> behavior of the multi-api which can always lead to side-effects.

It would unfortunately imply a rather drastic code modification, and one that
would also have to affect for example c-ares to be fully covering. If I
understand you correctly it would also break both API and ABI and thus warrant
new stuff to get added and the old way to be preserved for existing
applications which feels like... not a good idea.

-- 
  / daniel.haxx.se

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