Hello dear all,

My application works asynchronously using the curl_multi_socket_action
API.

It performs two simultaneous request transactions to the same server in
infinite loop, while using same connection.

The application hangs up at the first iteration.

The expected message flow for the iteration is:

-- Req A -->

-- Req B -->

<-- 401 A -

<-- 401 B --

-- Req A (+ authentication) -->

<-- 500 A --

-- Req B (without authentication) -->

<-- 401 B -

The libcurl version is 7.19.3-20081126, Win32 (XP SP2).

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.

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

because it is routed to the second element in the connection recv_pipe,
and

"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 caused my application to wait for response for the second Req B
forever, making it hangs up.

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.

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

What do you think of my analysis and the proposed solution?

Please find in the attachment the log generated by the libcurl and by
the application.

Note:

1. I added few extra print outs to the libcurl sources.

2. The log was collected until the application hung up.

Thank you,

Igor