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

This is exactly the solution I proposed in the first mail in this chain
:)
Do you want me to try to prepare the patch?

Thanks,
Igor
Received on 2008-12-04