On Sun, 25 Jun 2006, Armel Asselin wrote:

> One of the operations that i would like to permit in my app would to put
> into in FTP site a file that i just read from another FTP site. In order to
> reduce the time for the operation, rather than doing RETR all of the data
> then STOR aff all the data, I'd like to launch both operation in a multi
> handle and use the read/write callback functions so that each time new data
> come from write callback of RETR they are added to a queue and each time
> read callback of STOR is called i read from there and returns the data to
> put to Curl.

I can fully understand that wish.

> unfortunately i may encounter buffer underruns and it seems that read ( )
> should never return 0, else than when indicating end-of-file (as per
> curl_easy_set_opt doc, in 7.15.4 tar.gz). is it right?

Correctomente.

> if yes, is it imagineable to have a return value such as
> CURL_READFUNC_TRYLATER meaning that data is not yet here but it is expected
> to and at next curl_multi_perform the data would be available and the work
> would continue?

I've been expressing a wish for seeing this feature added for several years,
but nobody has ever been interested enough or had the time/skill for it.

However, the actual returning of a fixed code for the case is not the tricky
part. No, the tricky part is that when the connection has been deemed "ready
to receive data to send but the callback said we need to wait" we must NOT
make select() return instantly in the next loop again just because the socket
is still writable and then it'll call the read callback again and cause a
senseless busy loop until the callback returns another return code.

I would rather see it done by something in the manner of having these two
features added:

  1 - The callback can somehow tell libcurl that it can't return any data right
      now, but please call me again in NNN milliseconds *or* don't call me
      again at all until I tell you its OK again.

  2 - Have a way to tell libcurl that a given connection is now ready to again
      send away data for the (1) state to end.

Of course these are just my ideas. They can most likely be further improved.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html