On Mon, 1 Aug 2011, ajil koshy wrote:

>> curl_multi_info_read() is the definitive way.
>
> I am already calling curl_multi_info_read after calling curl_multi_perform
> (as mentioned earlier). This should probably return some kind of error,
> shouldn't it?

When exactly should it return an error when it currently doesn't?

> The problem is that I am observing intermittent behavior here.

Please be as detailed and thorough as you can, cause I'm not following exactly
what problem you see and what you think libcurl does wrong.

> In some cases, I see that calling curl_multi_info_read yields a connection
> closed error but on some other occasions, the loop just runs on and on.

And in what state is that connection? How do you verify in which state it is?

> Another observation is that the call to select () function used to wait on
> inbound data returns SOCKET_ERROR if peer application has exited.

Now wait a second. select() returns an error if one of the connections have
done what? How can select() know if the peer application "has exited"? Do you
mean it sent a RST or FIN on the TCP connection? Why would that cause select()
to return an error?

Can you point to any docs stating this?

> However, I cannot use this as a sufficient condition to break out of the
> multi-loop as I have observed that select call fails while data transfer is
> in progress too.

Correct, you should let libcurl detect the end of the transfer.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html