RE: hangs up of application above libcurl
Date: Thu, 4 Dec 2008 10:49:18 +0200
> > My complain is about algorithm that is used from within multi_socket
> > order to choose the handle to be passed to the multi_runsingle().
> > algorithm uses Curl_hash_pick(). The last brings the handle 11961a8
> > not in head of the recv_pipe of the connection, on which the data
> > received. As a result the other handle 118d350 is chosen. This other
> > is in the CURLM_STATE_WAITPERFORM state. But it doesn't move to the
> > 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
> Curl_hash_pick() function can (wrongly) fetch the one that isn't
> 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
> one of the pipes (recv and send). I guess the input action bit needs
> used as a hint to what pipe that should be checked. If it isn't first
> pipe for the checked direction, we can traverse the linked list with
> on that pipe and instead pick the one in the head and proceed using
> In general we will also need to go over all other uses of the sockhash
> sure that we don't remove entries from the hash that are part of a
> then we still want the socket in there for the remaining handles. Like
> 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?
Received on 2008-12-04