Twas brillig at 21:17:10 18.09.2009 UTC+02 when [email protected] did gyre and gimble:
PS> The number of bytes written may be less than count if, for example, PS> there is insufficient space on the underlying physical medium, or PS> the RLIMIT_FSIZE resource limit is encountered (see setrlimit(2)), PS> or the call was interrupted by a signal handler after having PS> written less than count bytes. (See also pipe(7).) It says "there might be less than count bytes written". It does not tell anything about blocking, so short writes should be handled as well, but it is not related to blocking/non-blocking. >> Why a kernel can't block on read/write on blocking socket? PS> Sorry, what? Socket is blocking. Why kernel can't block? >> Why reading From socket can't block if there is not enough data >> available on the other side yet? PS> Ok, for reading nbio solves the problem when an application wants PS> to use both a really problematic SSH fd and another very PS> unproblematic high throughput fd. Even though SSH has a nice PS> packetized protocol if there's congestion holding up incoming data, PS> that would indeed affect also the communicion on the other fd. PS> Chances are they are related anyway, or no? It depends on application (e.g. it may have SSH control channel and independent data streams). PS> I can certainly understand the motivation for nbio in a transfer PS> intense program, such as curl. I'm not so sure for libssh2. It PS> continues to cause a fair amount of problems. One of apps I wrote with libssh2 was really transfer-intense (it used SSH for a communication channel a-la rsync). >> Why writing to socket can't block if there is no buffer space >> available in network driver? PS> If there is no space at all select() should not indicate PS> writable. If there is little space, write() should return short. See the below for the SUSv3 excerpt. PS> If there was space, but then that changed into no space, isn't PS> select() just plain broken? There may be less space than needed. PS> If select() returns readable there is data, why would there PS> suddenly not be data anymore? SUSv3: "A descriptor shall be considered ready for reading when a call to an input function with O_NONBLOCK clear would not block, whether or not the function would transfer data successfully." It does not tell anything about blocking sockets. PS> If select() returns writable there is room for writing data, why PS> would there suddenly not be room for data (being written to the PS> kernel) anymore? SUSv3: "A descriptor shall be considered ready for writing when a call to an output function with O_NONBLOCK clear would not block, whether or not the function would transfer data successfully." It does not tell anything about blocking sockets. -- http://fossarchy.blogspot.com/
pgp2i4x473iaH.pgp
Description: PGP signature
_______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
