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