Re: curl_multi_fdset alternatives
Date: Fri, 9 Sep 2005 00:53:40 +0200
On Don 08.09.2005 14:28, Daniel Stenberg wrote:
>On Wed, 7 Sep 2005, Alexander Lazic wrote:
>>Looks very nice ;-) How can i help you to implement these idea?
>You tell me where I find a few extra hours per day for a month or so!
>If I'm very lucky, I get funded to do these changes later this year.
>>CURLMcode curl_multi_socket(CURLM *multi_handle,
>> curl_socket_t s,
>> CURL *easy,
>> curl_socket_callback callback,
>> void *userp); /* passed to callback */
>>do i understand this right that the 'app' make the
>>socket()/fctl(..$NONBLOCK..) calls and
>>curl_multi_init()/curl_easy_init() and then call the
>The socket() calls would be for the applications own use, right?
I think so.
>They can be created, used and waited for togather with the ones
But the app feed the curl_multi_socket() thefore curl_multi_socket()
should only have the sockets from the app.
I think this is the major problem because some functions make their own
>curl_multi_socket() calls the callback to inform the application about
>what sockets it uses and what actions to wait for on them. It also
>calls the callback when sockets are removed or if there's a change of
>action to wait for.
I think i have understood this, hopefully.
>The app should then wait for action on all sockets libcurl has told it
>about (and of course its own set of file descriptors).
Yes and the one which the libcurl create by it self also!
>A main difference from today is that you'd tell curl_multi_socket()
>exactly what socket that had action on it so that it wouldn't have to
>check all its sockets for that but only work on the actual socket that
I think this is a major redesign for libcurl, isn't it?
I have looked into 'curl-7.14.1/lib/transfer.c => Curl_readwrite()' which
is called by 'curl-7.14.1/lib/multi.c => curl_multi_perform()'.
Have i the right point of view from your site?
Now i understand what you have mean with the extra time.
Received on 2005-09-09