Hello, Daniel.

I apologies for such disappearance, because of some problems with my
mail.

Did any discussion was appeared without me and brought some
decision?

In the mailing list archive I have found the following:

> 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...

Are you intending that this curl_easy_pause() should be called outside
read/write callback? To prevent libcurl from reading bytes off the
connection and storage of them.

If so, it can cause problems in some circumstances.
Particularly, it can happen when operation block can be recognized
only on try to perform this operation.
Such situation is possible, for example in case of using
WinAPI:WaitForMultipleObjects for events demultiplexing. Event created
for socket writability checking becomes signaled only when
non-writable socket becomes writable. If socket already was writable,
the event never becomes signaled. So, developer has to wait for such
event only when send() returns EWOULDBLOCK, otherwise he will wait
forever.

I'm not sure that my example is very good, but I think such
circumstance should be considered while designing non-blocking
interface.

I think it still would be great, if non-blocking interface will be
designed in more usual fashion and reflect most of existent API.
I.e. operation blocking is displayed by the read/write callback
returning special blocking-result-code.

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