Re: [PATCH] pausing a transfer, take one
Date: Thu, 27 Dec 2007 17:19:57 +0600
Sunday, December 23, 2007, you wrote:
> Using this version of the patch with this version of your test code,
> it seems to work!
Thanks a lot, it works for me too. And thanks for bugfix of my code. :)
By the way, is it necessary to do the following?
code = curl_multi_perform(multi, &handles);
} while (CURLM_CALL_MULTI_PERFORM == code);
In the original code (without do-while loop) CURLM_CALL_MULTI_PERFORM
check appears in the switch(code) below:
case CURLM_CALL_MULTI_PERFORM: continue;
And it causes the next iteration and call of curl_multi_perform()
without performing curl_multi_fdset() and select(). But in this case
curl_easy_pause() can be called when curl_multi_perform returns
CURLM_CALL_MULTI_PERFORM. Is this forbidden?
I've attached new test code, which retrieves corrupted resource:
This one uses "Accept-Encoding: gzip,deflate". For small resources
(~20kb) it works good, but for large resources (~300kb), which
retrieval takes several write-callback calls, the resulting resource
is corrupted. If USE_PAUSE is disabled, everything works great.
By looking at the libcurl code, it seems that data will be corrupted
if Curl_client_write() is called several times per one
curl_multi_perform() call. Maybe I'm wrong, but looks like
Curl_ldap() and tftp_do() has the same issue. Maybe it can appear
Additionally, I've noticed that sometimes callback is called even if
previous call have returned CURL_WRITEFUNC_PAUSE, and curl_easy_pause()
wasn't performed yet. It appears for me in test_pause03.c .
This is not so critical, we can just return CURL_WRITEFUNC_PAUSE again
and everything looks going right. But maybe it is better to provide
more expected behavior?
-- Best regards, Dmitriy Sergeyev C++ Developer of ISS Art, Ltd., Omsk, Russia. http://issart.com
Received on 2007-12-27