[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: About non-blocking mode usage
[Thread Prev] | [Thread Next]
- Subject: Re: About non-blocking mode usage
- From: Aris Adamantiadis <aris@xxxxxxxxxxxx>
- Reply-to: libssh@xxxxxxxxxx
- Date: Tue, 04 Nov 2014 22:04:18 +0100
- To: libssh@xxxxxxxxxx
Hi, This is exact to the precision that it's waiting for the socket to be readable (and not writable). Since SSH has internal channel windowing, we use a write buffering strategy to avoid blocking the app when a write is pending. Aris Le 4/11/14 18:58, Doug Judd a écrit : > I confronted this issue as well. The documentation is lacking in this > area. It appears that most of the APIs, when they return SSH_AGAIN, > it means that you need to wait until the underlying socket becomes > ready for reading. I found this to be true for both connection > establishment APIs and command execution APIs. I suppose that if you > issue commands that are large, ssh_channel_request_exec() could return > SSH_AGAIN and require you to wait until the socket becomes ready for > writing, however, I'm not 100% sure on this. > > - Doug > > On Thu, Oct 30, 2014 at 4:55 PM, Liang Qin <lqin@xxxxxxxxxx > <mailto:lqin@xxxxxxxxxx>> wrote: > > Does anyone has an example of how to use the non-blocking mode for > libssh? > This include ssh_connect, ssh_userauth functions, ssh_channel > functions etc. these functions will return again in non-blocking > mode, in the test examples we see it just keep trying until we get > ssh_ok, but this is not efficient and will cause high cpu usage, I > know we should use poll or ssh_poll, but I did not find any docs > or examples that shows how to use it. > > Could anyone give me some example? > Thanks > > > > > -- > Doug Judd > CEO, Hypertable Inc.
Re: About non-blocking mode usage | Doug Judd <doug@xxxxxxxxxxxxxx> |