cURL / Mailing Lists / curl-library / Single Mail


RE: hangs up of application above libcurl

From: Igor Novoseltsev <>
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
that is
> > 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
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
> on that pipe and instead pick the one in the head and proceed using
> instead.
> In general we will also need to go over all other uses of the sockhash
> 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?

Received on 2008-12-04