On Tue, 1 Jul 2008, J.T. Conklin wrote:
>> Why so? We've made an effort to bring non-blocking functionality to
>> libssh2, why would an application using libssh2 suddenly not care about
>> that when it wants to close a SFTP handle?
>
> I suggested blocking because it seems conceptually simpler. After you close
> a handle, there's nothing more that can be done with it, as such it seemed
> natural to have close() block until it has completed? Now I suspect this
> opinion was formed due to my lack of direct experience with non-blocking I/O
> -- I usually use blocking or asynchronous I/O.
Yeah, and I am in the opposite camp! ;-) I'm always doing non-blocking
operations in a single thread. I imagine an application having 10000 SFTP
connections in a single thread, and when one of them wants to close down the
connection I don't want that single connection to block the other 9999 ones...
> But if there is a hard failure, as in the case of the underlying connection
> being closed, I think libssh2_sftp_close_handle() has to complete, as no
> amount of retries are going to complete the close.
Yes indeed, returning "try this again" is a blatant bug if there's nothing to
try again. Like if the connection has been closed in the other end already,
libssh2 should simply cleanup all its own stuff and return fine.
-- / daniel.haxx.se ------------------------------------------------------------------------- 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_at_lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libssh2-develReceived on 2008-07-02