On Tue, 30 Oct 2007, Dmitriy Sergeyev wrote:
> We can specify read function by setting up CURLOPT_READFUNCTION. And
> this function will be called each time when libcurl needs for next
> block of data to send. But if such data is not currently available,
> the only way is to block read function and wait for data. It is
> obvious that this it is very unpractical in case of handling of
> several connections within one thread via multi-handle.
> Maybe it is good idea, to add non-blocking ability for read function?
> I'm not very good in libcurl source code, but looks like there is some
> kind of state machine inside it. Therefore, maybe addition of such
> functionality shouldn't be so hard? For example, read-function can
> return some special code, which disables read calls for a while, until
> some enable-read-function will be called for appropriate easy-handle.
I agree that we could indeed have use for such a feature (for both upload and
download), and that's pretty much what I meant with the paragraph in the TODO
* Make transfers treated more carefully. We need a way to tell libcurl we
have data to write, as the current system expects us to upload data each
time the socket is writable and there is no way to say that we want to
upload data soon just not right now, without that aborting the upload. The
opposite situation should be possible as well, that we tell libcurl we're
ready to accept read data. Today libcurl feeds the data as soon as it is
available for reading, no matter what.
Do you have a suggested API on how this could be controlled by the
Commercial curl and libcurl Technical Support: http://haxx.se/curl.html
Received on 2007-10-30