Tor Arntsen wrote: > select(2) doesn't know how much you want to write (or read),
It doesn't have to. > I.e. if there's one byte available at a socket it will tell you the > socket is ready. When you try to read 100 bytes you'll block in > read(), if not set to non-blocking. Run strace nc localhost 22 and you see this is not true: read(3, "SSH-2.0-OpenSSH_5.2\r\n"..., 8192) = 21 read() is allowed to return short. It does not have to wait until 100 or 8192 bytes have come in, and in your example I expect it to return the one byte it has available. > The same can be the case with writing: There's room to write a > byte, so the socket is ready, there may not be room to write all > your bytes (e.g. window filled). write() too is also allowed to return short. It takes the bytes it can off my hands, returns the amount, and if I want to get rid of more bytes then I call select() again to wait for the next opportunity. > And, independently of blocking vs. nonblocking, read(2) or write(2) > can always return short when working on sockets (due to lots of > things, e.g. if some signal somewhere else in the application > interrupted the call). If the process gets a signal then they will not return short, but an EINTR error code. //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
