cURL / Mailing Lists / curl-library / Single Mail


Re: proposal for new curl_mutli_socket API

From: Daniel Stenberg <>
Date: Sat, 26 Apr 2008 22:17:51 +0200 (CEST)

On Fri, 25 Apr 2008, Christopher Palow wrote:

> So thatıs cool. As you suggested the man pages and web pages are a little
> out of date though (see below). Iıll gladly write up a little update if you
> like.

Oh yes please! As a matter of fact, with this change it struck me that
curl_multi_socket_all() has very little reason for existance. I mean, forcing
a check for all easy handles should really never make any difference (I mean
apart from not having to wait 10 ms which really is a time I can't see how any
app could be concerned about).

> I wonder about the whole rely on a timeout 10 millisecs in the future scheme
> used to transition from states here and in multi_runsingle() [the setting
> result=CURLM_CALL_MULTI_PERFORM method]. How about just setting a flag that
> says call multi_runsingle() again immediately. Iıll code up a patch if you
> think it has some validity.

"a flag" can't work easily, since you may add N handles at once and you want
exactly those handles taken care of "soon". Of course we could add a new
linked list with handles to take care of ASAP but that would just introduce a
second queue for roughly the same meaning and I don't think the gain outweighs
the added code complexity. Do you?

> I also discovered a bug that Iıll submit a patch for in a little while that
> is related to the just expire in 10 millisecs scheme (though I fixed it a
> different way).

Bug fixes are always very welcome!

> Finally, I reworked my patch (more code reuse) even though itıs no longer
> needed for starting connections. I think it still has some validity if
> youıre keeping around the easy pointer thatıs associated with a fd. While
> poll() and select() donıt allow you to pass a private pointer into the
> kernel to be associated with file descriptor, epoll() does. Basically it
> ends up being the same as curl_multi_socket() where you donıt pass in an
> ev_bitmask and without a hash table lookup.

Ah you mean the app magically knew what specific easy handle the socket-action
is connected to and then just wants that easy handle taken care of?

How would it know that in the first place since the multi_socket API only
informs the apps about sockets, not easy handles? To me it seems like a
function that very very few people would ever use, and even them could use the
one(s) we already provide instead. Or am I missing something?

  Commercial curl and libcurl Technical Support:
Received on 2008-04-26