On Thu, 25 Sep 2008, Vlad Grachov wrote:

> When libssh2 is set to non-blocking mode its functions return
> LIBSSH2_ERROR_EAGAIN
> if recv/send returned EAGAIN. Upon receiving LIBSSH2_ERROR_EAGAIN curl's
> state machine just repeats the same step (without a call to select/poll).

It does? Can you detail more about what the particular code/function sequence
that is (not) doing this? It is certainly a bug. Perhaps you even have a patch
to propose?

But you should also be aware of the fact that there's still a signigicant flaw
in the libcurl <=> libssh2 communication that will lead to occaional
busy-loops even when poll() is used:

libcurl waits for socket actions based on what direction the transfer is.
Alas, if you download data libcurl will wait for the socket to get readable
and then call libssh2 to get that data. But libssh2 itself both recieves and
sends data during this call and it can very well return EAGAIN when it _sent_
data and then libcurl can immediately discover that the socket is indeed still
readable and call libssh2 again that returns EAGAIN... until the socket
becomes writable and libssh2 can continue with its operations.

The fix for this problem has to be made in the libssh2 end and then libcurl
needs to adapt to it. My suggested approach is to add a function to libssh2
that says in what direction in wants data when EAGAIN is returned, so that
libcurl can wait for the proper situation to occur.

I'd love some help on getting all these problems fixed. (lib)curl is
continuously getting more and more users and attention and my list of things
to do is growing faster than I manage to complete previously added issues.

BTW, consider taking the further details on the curl-library list where most
of the hard core libcurl hackers hang out.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html