On Fri, 9 Sep 2005, Alexander Lazic wrote:

>> They can be created, used and waited for togather with the ones
>> curl_multi_socket() provides.
>
> But the app feed the curl_multi_socket() thefore curl_multi_socket() should
> only have the sockets from the app.

I don't understand what you mean. curl_multi_socket() will tell your app what
sockets it uses and then your app waits for actions on the sockets. libcurl's
and your own. Using the method of your choice.

It should make it possible to use any high-performance lib or method.

It should make libcurl a huge step closer to dealing with the c10k problem.

Of course, nothing of this is carved in stone yet so we can still tune how
these functions should behave.

> I think this is the major problem because some functions make their own
> socket()/connect() calls.

The application's sockets, connects etc are not a concern of libcurl. The
application deals with its own sockets.

>> 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
>> needs attention.
>
> I think this is a major redesign for libcurl, isn't it?

It isn't really a redesign, but it is a pretty big change yes.

Hopefully, it should make libcurl a lot better performing when you use it for
huge amount of simultanoues transfers.

This fix, together with added HTTP pipeling support, ought to make libcurl
outperform most of the competition.

> Now i understand what you have mean with the extra time.

:-)

With a full time job and a real-life family, the day just don't have enough
hours.

I expect this API to get added eventually, but I can't tell when. Hopefully
there will show up a company that finds out it wants this added that pays
someone to make the changes.

I'll appreciate help of course.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html