cURL
Haxx ad
libcurl

curl's project page on SourceForge.net

Sponsors:
Haxx

cURL > Mailing List > Monthly Index > Single Mail

curl-library Mailing List Archives

Re: CURLM_CALL_MULTI_PERFORM and curl_multi_socket

From: Nathan E. Moore <nate_at_redtetrahedron.org>
Date: Sun, 01 Jun 2008 18:19:43 -0400

--On Sunday, June 01, 2008 11:17 PM +0200 Daniel Stenberg <daniel_at_haxx.se>
wrote:

> On Sun, 1 Jun 2008, Nathan E. Moore wrote:
>
>> I just tried with cvs. With the changes to ignore CURLM_BAD_SOCKET,
>> this obviously never happens, but if I don't ignore CURLM_BAD_SOCKET it
>> does.
>
> I don't get it. I've removed the previous way it returned
> CURLM_BAD_SOCKET for curl_multi_socket() so you shouldn't ever get it. In
> your patch you re-introduce it and then you get the error code. Why do
> you re-introduce it?
Because there is no point in testing it without it. The removed check is
where I am seeing the failure, this check was removed to deal with a
libevent issue, but my issue has nothing to do with libevent.
>
>> calling curl_multi_socket with fd=28
>> STATE: PERFORM => DONE handle 0xb80a9038; (connection #21)
>> socket callback: s=28 e=0xb803da78 what=REMOVE
>> multi_timer_cb: Setting timeout to 1 ms
>> calling curl_multi_socket with fd=28
>> ERROR: event_cb: curl_multi_socket returns CULRM_BAD_SOCKET
>
> See, you're getting the exact same procedure I was talking about: libcurl
> asks your app to remove fd 28 yet just milliseconds later you call
> curl_multi_socket with action on that very same file descriptor. libcurl
> then knows nothing about it anymore. In current CVS that's not a reason
> for failure since I believe the above happens due to some weird
> effect/behavior of libevent and besides I don't see any particular reason
> for libcurl to be that picky.

the behaviour I am seeing is
1) I call curl_multi_socket with socket=28 (number is irrelevant)
2) curl calls my socket callback to remove socket=28
3) curl_multi_socket returns CURLM_CALL_MULTI_PERFORM
4) I call curl_multi_socket with the same arguments as in 1
5a) curl_multi_socket reuturns CURLM_BAD_SOCKET (7.18.1 behavior)
5b) curl treats my call with a unknown socket just as I had called with
CURL_SOCKET_TIMEOUT (cvs behavior)

Is curl_multi_socket returning CURLM_CALL_MULTI_PERFORM after removing the
socket it is acting on the expected behavior? What are the correct
argument to use with curl_multi_socket when you get a return value of
CURL_CALL_MULTI_PERFORM?

Nathan Moore
Received on 2008-06-02

These mail archives are generated by hypermail.

donate! Page updated November 12, 2010.
web site info

File upload with ASP.NET