Daniel Stenberg wrote: > You're basically basing that assumption on that recv() and send() > will return and behave identically if it was blocking.
I didn't consider recv() and send(), actually only read() and write(). > And if they would return immediately in blocking mode as it does in > non-blocking mode, they would behave the same as the code does now > and we would gain nothing by switching! Of course non-blocking and blocking io will be implemented differently, and I brought this up because I think blocking would be simpler. > But the reality is that blocking sockets do in fact cause send(), > recv() and friends What friends? > to block at times when non-blocking don't Even if select() has predicted that they will not? This is the pivotal question. > Let me for example quote a little piece from the send() man page: > > When the message does not fit into the send buffer of the socket, > send() normally blocks, unless the socket has been placed in > non-block‐ > ing I/O mode. Right - because send(), unlike write(), doesn't return short. Oh, and is that the only reason for having a buffer size? To determine how big chunks to send() at a time? Why is it desirable to use send()/recv() rather than write()/read()? //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
