Hello, Daniel.

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?
==========
        do {
            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:
test_pause02.c
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
somewhere else.

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