On Tue, 30 Oct 2007, Dmitriy Sergeyev wrote:

> So, my suggestion for the API is the same as in previous letter. Read and
> write callbacks can return some special code, which disables read/write
> calls for a while, until some enable-function will be called for appropriate
> easy-handle.
>
> For example, our implementation of read callback reads data from another
> socket and receives EWOULDBLOCK. We return "special code"
> (CURL_READFUNC_PAUSE for instance), and after that libcurl is pause calling
> read callback.

There's one little problem with this approach: the write callback. When that
is called, libcurl has already read N bytes off the connection and wants the
application to store them. Getting a "PAUSED" code back then would mean that
libcurl will have to keep a buffer of data around until the application again
says it wants it, and then it must pass the data to the application without
waiting for more data first.

It would be an easier implementation to just introduce a new function
curl_easy_pause() that pauses or unpauses an upload or download (or both). I'm
not saying the easiest route is always the preferred, I'm just thinking out
loud...

> It would be great, if curl_easy_continue_read() can be called at any time in
> main loop, regardless of what actually returned by previous call of
> read-callback. For example, it allows us to just always call
> curl_easy_continue_read() when FD_ISSET(rdhandle) is true, and not to worry
> about previous read-callback return code.

Uhm, I'm not sure I follow this reasoning. I think we can proceed to document
the newly suggested behavior in more exact details, as that'll make it easier
to discuss the specifics.

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