cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re[2]: non-blocking read function

From: Dmitriy Sergeyev <dsergeyev_at_issart.com>
Date: Tue, 30 Oct 2007 20:34:59 +0600

Hello, Daniel.

Thanks for such fast response.

> Do you have a suggested API on how this could be controlled by the
> application?

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.
In main loop with curl_multi_perform() we're performing select() on
socket from which we read data. When it become available to read, we
call something like curl_easy_continue_read(easyhandle), where
easyhandle is appropriate easy-handle with our read callback.
After that, libcurl continues calling of read-callback, until it
returns CURL_READFUNC_PAUSE again.

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.

Of course, everything should work as usual, if CURL_READFUNC_PAUSE
wasn't returned by callback. In this case, curl_easy_continue_read()
is never required for callback to be called.

This looks quite simple and useful for me. And it completely backward
compatible with already existent implementations.
Thanks.

--
Best regards,
  Dmitriy Sergeyev
C++ Developer of ISS Art, Ltd., Omsk, Russia.
http://issart.com
Received on 2007-10-30