On Thu, 16 Jul 2015, Cristian Morales Vega wrote:

>> 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).

The splay tree is sorted on expire time (for the internal timeout expiry), and
the expire times are done on a millisecond resolution so basically all handles
added at the same millisecond will be handled a bit "randomly" initially.

> Right now I'm not even sure why a splay is being used,

It keeps all the added handles in a sorted tree so that libcurl can quickly
find the timed out handles and to add new handles into to the sorted tree (and
removing an entry and putting it back in a new place).

The problem the splay tree is there to solve is that all N easy handles (where
N can be 10K or more) have their own expire timeouts and libcurl needs to be
able to walk through the Z ones that have expired. And also tell how long time
it is until the next one expires. The splay tree solves this rather elegantly
and with decent performance.

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