cURL / Mailing Lists / curl-library / Single Mail

curl-library

RE: hangs up of application above libcurl

From: Igor Novoseltsev <IgorN_at_radvision.com>
Date: Wed, 3 Dec 2008 19:16:22 +0200

> > 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?
>
> It doesn't sound like that, no. When libcurl is waiting for a read
event, it
> should have called the app using the socket callback saying so, so
that the
> app will wait for a READ event and properly call libcurl when such an
event
> arrives.

By "On READ event" I mean "When curl_multi_socket_action() is called
with READ action bit set".

> > 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.
>
> When curl_multi_socket_action() is called with the READ action bit
set,
> lib/multi.c:multi_runsingle() will be called and if the handle is then
in the
> PERFORM state it will call Curl_readwrite() that will act according to
the
> bits you passed to curl_multi_socket_action().

My complain is about algorithm that is used from within multi_socket
in order to choose the handle to be passed to the multi_runsingle().
This 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 was received.
As a result the other handle 118d350 is chosen. This other handle is in
the CURLM_STATE_WAITPERFORM
state. But it doesn't move to the PERFORM state because it is not in the
head of the recv_pipe.
 

> > I suspect that the READ event that was ignored stands for the
received
> > response.
>
> What is curl_multi_socket_action() doing then when you call it with
the READ
> action bit set? In what state is the multi handle at that point?

As it was mentioned before - in CURLM_STATE_WAITPERFORM.
You can see this in the log I attached early.
The multi handle is 118d350. It is in the second place of the recv_pipe.
At the head the handle 11961a8.
I attach the log again for your convenience.

Thank you,
Igor

Received on 2008-12-03