Daniel Stenberg wrote: >> Aha. But then send() will also succeed (and possibly return short) >> on a socket which was predicted by select() to be writable. > > Yes of course. But the thing is that a non-blocking send() will > never block while a blocking one might - after select() has > signalled the socket to be writable.
That seems to go against select(2), although I admit "a write" does not say which function calls count. Have you seen this actually happen? If so, on which systems? >> I saw a note about MSG_NOSIGNAL in your portability notes. Is this >> it? If so, why is it important? > > Because we don't want to bother our app with signals that isn't its > business (and we don't have any signals documented in our API). Other end of it's SSH connection disappeared would be it's business. I agree signals are a little crude. > And signals don't work properly in multi-threaded environments. Well, I've used them, but no, it's not nice. Could we block or ignore SIGPIPE to satisfaction in the library? Or even let the app decide to block or not? //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
