On Fri, 18 Sep 2009, Peter Stuge wrote:
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)
Not at all. The socket being writable according to select() doesn't imply that
a write() or send() in blocking mode will return immediately.
Have you seen this actually happen? If so, on which systems?
Blocking mode causes these functions to block at times, it's not too strange a
concept. It is like that on all POSIX like systems, of course to varying
degrees depending on how the internals work.
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.
Of course, but that doesn't mean we have to send the app a signal.
And signals don't work properly in multi-threaded environments.
Well, I've used them, but no, it's not nice.
In some environments they can't even be used in multi-threaded situations but
will instead cause serious hiccups.
Could we block or ignore SIGPIPE to satisfaction in the library?
No. We would have to add the block on every entry-point and remove the block
on every exit-point. For what purpose?
Or even let the app decide to block or not?
Why? We already have a defined API, what's wrong with it?
--
/ daniel.haxx.se
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
