On Wed, 13 Jul 2011, andrew S wrote:

>> Your use of curl_multi_fdset() with the multi_socket API sounds rare so it
>> wouldn't surprise me if there's something not properly polished there.
>
> If this use of cURL sounds rare, what would be a more common way?

As the multi_socket() is a way to get to know which sockets libcurl uses
without implying select() and as it is event-friendly, most users would pass
the socket(s) on to an event-based library or function straight from the
socket callback.

When the event-based system tells us there's action on one of the supervised
sockets, the curl_multi_socket_action() function gets called.

> In our applications we need to perform not only sequential, but mainly
> parallel transfers, and we need to poll not only on curl-provided sockets,
> but on other sockets too.

The event-based systems I've used such as libev and libevent have no problems
to wait for additional file descriptors!

> Should we completely rely on CURLMOPT_SOCKETFUNCTION callback to control
> read and write fdsets?

That's what I've done and what I've assumed every socket_action API user would
do. I'm not saying you've done something wrong, but as it hasn't been what
we've designed this for and I think not many have used the API that way there
may be remaining problems there.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html