I just ran into bug 1355 (CURL_POLL_REMOVE callback occurs after close call rather than before), and there are a couple of points I'd like to make about it as a counterargument to the ones made before on the bug's closure message.
1. If you're using Linux epoll with curl_multi, it's useful to be able to detach your socket from epoll before you close it. 2. In Windows, there is similarly the API call CancelIoEx. 3. Some applications, like the one in which I encountered this problem, have a socket loop where socket closure always happens with an empty call stack and only when an internal reference count hits zero. This is problematic when the socket is already gone. 4. The "secondary socket" mechanism appears to bypass CURLOPT_CLOSESOCKETFUNCTION in Curl_closesocket in a simple inspection. If so, that severely limits the usefulness of that option, because it means that as soon as libcurl uses a secondary socket then closes it, our application will assert. I personally feel that certain parts of libcurl's design are flawed. In my opinion, libcurl ought to have the entirety of its socket code factored out into a separate set of object files. All socket calls would go through the callback system on curl_easy_* or curl_multi_*. The socket implementation would merely provide the default implementation of the callbacks. A "socket" would merely be an intptr_t parameter to these callbacks. There'd be a lot more callbacks - a callback to disable Nagle, for example - but this'd work. This would allow the use of libcurl over things that are distinctly not sockets, such as Win32 named pipes. It'd also make libcurl usable in more environments, such as where a BSD-compatible socket environment doesn't exist (such as in the NT kernel - winsock is a user-mode BSD socket layer API wrapper on top of the native implementation). Melissa ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
