Subject: [libssh2] EAGAIN but waiting for what?

[libssh2] EAGAIN but waiting for what?

From: Daniel Stenberg <>
Date: Thu, 3 Jul 2008 13:15:36 +0200 (CEST)


I'm pondering about fixing one of the biggest flaws we have in libcurl's use
of libssh2 for SCP and SFTP transfers, but in order to do this in a
non-hackish way I think I need to modify the libssh2 API and I thought I'd ask
for some general advice here.

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.

To be able to fix this, we need to be able to query libssh2 for what
particular action it returned LIBSSH2_EAGAIN for, or rather perhaps what
condition it wants to see fulfilled before I should bother to call it again.

I suggest we introduce a new function:

int libssh2_session_getfd(LIBSSH2_SESSION *session, int *socket, int *action);

This function will simply store the socket this session is using, and a
bitmask of actions (READ and/or WRITE) it currently waits for. It returns a
failure if it doesn't know.


Sponsored by: 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
libssh2-devel mailing list
Received on 2008-07-03