cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: curl_multi_socket_action and pipelining

From: Cristian Morales Vega <cristian_at_samknows.com>
Date: Thu, 16 Jul 2015 16:16:15 +0100

On 20 June 2015 at 00:31, Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Fri, 19 Jun 2015, Cristian Morales Vega wrote:
>
>>> This said, we don't make it "random" on purpose and I'm not aware of any
>>> particular functionality what would prevent libcurl from doing them in
>>> order.
>
>
>> Would adding the in-order guarantee make sense?
>
>
> I'm not convinced. I depends on what the exact reason is for why it doesn't
> do them in order right now. I'm prepared to say that it should try to do
> them in order, but I'm not sure it is wise to add as a firm promise.
>
> Do you know what internal mechanism that makes them not get done in order?

I have not checked it in detail. But it's because of the
multi->timetree splay. It seems that depending on how timeouts expire
the order they are processed in multi_socket() changes (and the common
case is that the last easy handle added is the first to be requested).
Right now I'm not even sure why a splay is being used, or when
elements are added/removed to it. I don't think I will get the chance
of looking into it any time soon.

>> I want the in-order guarantee because I'm downloading chunks of video.
>
>
> I can see how you want this. But I'm not sure that the mere fact that you
> add transfer A before transfer B must imply that A uncodntionally gets onto
> the pipelines before B.
>
> But I'm certainly open for providing means to make sure that libcurl can
> offer that functionality. Maybe we should use dependencies for this purpose
> too and make sure that we can guarantee orders like that based on what
> stream dependencies are set.

Extra work, but the dependencies would make a lot of sense.

> In general however, just adding the second handle X milliseconds after the
> first handle will make the second transfer get done after the first...

Not ideal. But sure, for simple cases that would be enough.
For the time being I think I will just change the
curl_multi_socket_action() calls for curl_multi_socket_all() which,
*in our current version of libcurl*, uses a different multi_socket()
code path which seems to guarantee the order.

Sorry for not being able to help with this.
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2015-07-16