Hi Aviv, It's not sure we will do this, because of the expected behaviour of the function when the nonblocking write "fails" (write would block): should we report the number of bytes correctly sent through send(2), SSH_AGAIN. Should we buffer that data or ignore data that couldn't be sent (like send(2)). All of this is not obvious to define and the latter is not obvious to implement either. We may wrap the current behaviour (bufferize data to be sent and returning SSH_AGAIN if buffer not empty), but don't hold your breath on this, current libssh development is slow.
Kr, Aris Le 24/05/12 13:44, Aviv Zilberman a écrit : > Does libssh plan to wrap it in a simple API (like > ssh_channel_read_nonblocking) ? > > -----Original Message----- > From: Aris Adamantiadis [mailto:[email protected]] > Sent: Thursday, May 24, 2012 2:40 PM > To: [email protected] > Subject: Re: Non blocking write > > Hello, > > ssh_set_fd_towrite() is a misnamed function that tells libssh the write > won't block of the file descriptor. It may have the opposite action as > you'd expect. > The best way of doing nonblocking write is to use > ssh_channel_set_blocking + ssh_channel_write, then use > ssh_handle_packets to have libssh flush the socket when it's possible > (however this function is currently private, we'll export it later), and > use ssh_blocking_flush with a timeout to flush the buffer. > A return code of SSH_AGAIN means there's still data to be flushed out. > > Kr, > > Aris > > Le 21/05/12 09:13, Aviv Zilberman a écrit : >> *Hi ,* >> >> * * >> >> *Does ssh_channel_write become non-blocking already ? * >> >> *if yes, in which version ?* >> >> *If not, does calling to “ssh_set_fd_towrite” or >> “ssh_set_blocking(session, 0)” or “ssh_channel_set_blocking(channel, 0)” >> will help ?* >> >> * * >> >> *Thanks in advance,* >> >> *Zilberman Aviv.* >> >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please inform >> us by e-mail, phone or fax, and then delete the original and all copies >> thereof. >> > > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform us by > e-mail, phone or fax, and then delete the original and all copies thereof. >
