Daniel Stenberg <[EMAIL PROTECTED]> writes:
> We use libssh2 entirely non-blocking as we can have N number of
> simultanoues transfers in the same single thread. When
> LIBSSH2_EAGAIN is returned we go back and wait for action on the
> socket and then we call the same function again when action has
> happened.
>
> But what action should we wait for?
>
> In the download case, transferring data from a SCP/SFTP server
> libcurl assumes that we need to wait for the socket to become
> readable. This assumption is silly since both SCP and SFTP send/get
> data both ways during transfers. Thus, there are times during
> download when libssh2 returns LIBSSH2_EAGAIN for its internal _send_
> and since libcurl still waits for read it'll immediately call
> libssh2 again and we are in busy-loop hell (until the socket
> actually becomes writable). And vice versa of course.
FWIW, Just yesterday I learned that OpenSSL operations return either
SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE with a non-blocking BIO.
This seems better to me than having the library return an error code
indicating that the operation must be retried and requiring a second
call to find out whether an underlying read or write (would have)
blocked.
--jtc
--
J.T. Conklin
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
libssh2-devel mailing list
libssh2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libssh2-devel
