www.libssh2.org | Daily snapshots | Mailing list archive | Docs | Examples | github

Archive Index This month's Index

Subject: Re: [libssh2] RFC on non-blocking changes and suggestions - part 1

Re: [libssh2] RFC on non-blocking changes and suggestions - part 1

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Thu, 19 Apr 2007 22:56:19 +0200 (CEST)

On Thu, 19 Apr 2007, James Housley wrote:

> I created a non-blocking version of libssh2_sftp_readdir(), like
> libssh2_sftp_read() and libssh2_sftp_write().

Great! You mean like their *nb() versions?

> While these functions "set" the mode to non-blocking, it isn't even close.

Right, they still have issues left to fix before they are properly
non-blocking. The API is there and an application can still pretend it is non-
blocking, but the functions will block due to how they are still written.

> My most serious problem is in the bottom while loop in
> libssh2_sftp_packet_read(). If I get PACKET_EAGAIN from
> _libssh2_channel_read() to be non-blocking something has to be done with the
> data that has been read. My first thought was to just call
> libssh2_sftp_packet_add() with the data and number of bytes that have been
> received. This crashes nicely, because the header of the packet gives a
> different length then what is there. My second option is to temporarily
> store the packet in the _LIBSSH_SFTP structure and use that to allow the
> bypassing of the top portion of libssh2_sftp_packet_read() and just start
> reading.

I think you should introduce a state in that structure to start with so that
you can return out from the function and when called again you know where to
continue. But also to collect partial reads in a temporary buffer until a
complete one is received and can be "passed on".

> Then the temporary storage would need to be removed in case of other errors,
> might be hard to get right.

Why? The LIBSSH2_SFTP handle would remain allocated even today until properly
closed and there wouldn't be any difference if you add some more data to it,
it would just be more memory that could leak. libssh2_sftp_shutdown() could
simply be made to free it.

Or am I missing something?

> Attached is my code changes as they stand, edited with TAB for indent set a
> 4 spaces (like the original code in the library).

If you use tabs for indent and have no maximum line lengths, then there's no
particular fixed width for tabs!

This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
libssh2-devel mailing list
Received on 2007-04-19

the libssh2 team