On Wed, 9 Mar 2005, Justin Hammond wrote:

> The only thing I think I can offer as a option to consider is that the
> Curl_socket_callback function should also be passed a timeout, so If people
> use curl_multi_update after they submit the request to Curl, and
> curl_socket_callback specifies a timeout, then at least if there no activity
> on any of the curl sockets with X seconds (or whatever) we can still call
> curl_multi_socket when the timeout expires.

You mean like a maximum time we can allow the app to wait without action
before it should call curl_multi_socket() anyway? I've been intending to add
such a function before, and maybe the time has come now... It is useful for
the existing curl_multi_perform()-using apps as well.

I don't see how it can be useful with a timeout in each socket callback call?

> You might be thinking, but the curl_multi_* functions are called on every
> loop of the mainloop, well, if you look at at lot of the event libraries,
> they wrap up the entire mainloop, and its difficult to get our own functions
> included into the mainloop. In the case of libevent, the only way would be
> to create a Timer in libevent that curls curl_multi_update every 0(!)
> seconds

> This avoids the cases in those applications where Curl is not the main *HOG*
> on network communications. It will allow us to only call
> curl_multi_update/curl_multi_socket when we know there is going to be some
> curl activity rather than every loop of the mainloop

I'm afraid I don't quite follow you here, very possibly because I know nothing
about libevent or how you use it.

Can you elaborate a bit, perhaps with a little snippet of pseudo code on how
it would work?

> Another option that might be worthwhile considering is having
> curl_multi_update called only once when initilizing curl, and then curl
> itself calling the curl_socket_callback when there are changes internally by
> curl automatically. This avoids on extra call on each loop, and would make
> curl integrate a lot easier (as well I suspect, have a minor performance
> boost around the mainloop area, but its *debatable* if the extra overhead
> for curl to check the socket status at the end of each of its iterations
> will offset any further performance boost)

The reason I didn't integrate it, is that I was thinking that _always_ calling
the callback on socket changes might cause a lot of extra calls since a socket
change might get changed again later before the app get a chance to wait for
anything on it.

> Then only when there is socket or a timeout for Curl, we call
> curl_multi_socket?

Using curl_multi_timeout() [*], you'd never call curl_multi_socket() "in vain"
either.

> (P.S: I watch the mailing lists via Gname rather than being subscribed to
> the list, but thought about posting this to you as I felt it was important.)

Thank you. I appreciate it a lot.

[*] =

/*
   curl_multi_timeout()

   Returns the maximum number of milliseconds the app is allowed to wait before
   curl_multi_socket() or curl_multi_perform() must be called (to allow
   libcurl's timed events to take place) to keep internal timeouts etc working.

*/
CURLMcode curl_multi_timeout(CURLM *multi_handle
                             long *milliseconds);

-- 
      Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
       Dedicated custom curl help for hire: http://haxx.se/curl.html