It looks like I totally misunderstood the traced code.

Could you advice please, what details can help to understand the
problem?
Do you want me to add some prints to the log, attached to the mail?

Meanwhile I'll try to explain how did I get the conclusions.
But before that I would like to get your opinion regarding the phenomena
itself:

On READ event libcurl neither reads from the socket nor registers for
the READ event again.
Is it legal flow?

In the attached log you can see,
that the Curl_read() (look for "Curl_read") was not called after the
last READ (look for "events=0x1") event.

I suspect that the READ event that was ignored stands for the received
response.
As a result of ignoring, the response is not handled causing the
application to stuck.

Respectfully yours,
Igor

-----Original Message-----
From: curl-library-bounces_at_cool.haxx.se
[mailto:curl-library-bounces_at_cool.haxx.se] On Behalf Of Daniel Stenberg
Sent: Wednesday, December 03, 2008 12:34 AM
To: libcurl development
Subject: Re: hangs up of application above libcurl

On Tue, 2 Dec 2008, Igor Novoseltsev wrote:

> My application works asynchronously using the curl_multi_socket_action
> API.

Enabling pipelining too I conclude.

> While analyzing the hang I found, that matching of the received socket
event
> to the easy object is based on some timing (see Curl_splaygetbest in
> multi_socket), when the pipes are not taken into consideration.

That splay tree is only used for timeouts, and timeouts are set on a per

easy-handle basis. Timeouts that have expired will thus cause action to
be
taken. I don't follow you how they are related to the problem you
describe.

> As a result I get a situation when the READ event is ignored,

As a result of timeouts?

> "if(!easy->easy_conn->readchannel_inuse &&
> isHandleAtHead(easy->easy_handle, easy->easy_conn->recv_pipe))" in
> multi_runsingle.do.switch case CURLM_STATE_WAITPERFORM prevents the
READ
> event to be processed.

This means that if the receiving "channel" isn't in used but the
specific
connection is first in the receive queue it will be moved there.

> This caused my application to wait for response for the second Req B
> forever, making it hangs up.

Sorry but I don't understand how it ends up in this situation.

> From this point of view the possible fix can be on receiving READ
event for
> socket to find the first element in the recv_pipe of the connection,
taken
> from the easy object, which is bound to the socket using the socket
hash.

But if there's a connection in the receive pipeline, why won't the app
get a
READ event if there's data to be read?

> If no such element is found - fallback to the current mechanism which
uses
> Curl_splaygetbest().

Not exactly, that handles timeouts and if you don't have anything
particular
to timeout on you won't get any.

I'm afraid I need more details or a more elaborate description to
understand
what you're saying!

-- 
  / daniel.haxx.se