On Wed, 3 Dec 2008, Igor Novoseltsev wrote:

> My complain is about algorithm that is used from within multi_socket in
> order to choose the handle to be passed to the multi_runsingle(). This
> algorithm uses Curl_hash_pick(). The last brings the handle 11961a8 that is
> not in head of the recv_pipe of the connection, on which the data was
> received. As a result the other handle 118d350 is chosen. This other handle
> is in the CURLM_STATE_WAITPERFORM state. But it doesn't move to the PERFORM
> state because it is not in the head of the recv_pipe.

Aah. Now I see and how I completely understand why that isn't right.
multi->sockhash simply keeps sockets in the hash and when doing HTTP
pipelining more than one easy handle can use the same socket and thus the
Curl_hash_pick() function can (wrongly) fetch the one that isn't currently in
the head of the recv_pipe.

I think we can solve this particular issue like this:

If the extract SessionHandle is part of a pipe we can check if it is first in
one of the pipes (recv and send). I guess the input action bit needs to be
used as a hint to what pipe that should be checked. If it isn't first in the
pipe for the checked direction, we can traverse the linked list with handles
on that pipe and instead pick the one in the head and proceed using that
instead.

In general we will also need to go over all other uses of the sockhash to make
sure that we don't remove entries from the hash that are part of a pipe since
then we still want the socket in there for the remaining handles. Like in the
sh_delentry() function.

-- 
  / daniel.haxx.se