On Sun, 20 Sep 2009, Mikhail Gusarov wrote:
Actually, select() specification makes non-blocking sockets nearly useless.
Why do they exist at all? Just as a convenient shortcut for "select with 0s
timeout + read/write"?
You could also just reverse the question: with select(), blocking sockets and
recv() and send() that will return on short reads and writes, why bother to
have the socket blocking?
As I read Peter's original question on this subject, it was about how we could
simplify libssh2 internals by instead using blocking sockets as the
state-saving business is a bit ugly and kludgey at times.
But the reality is, and we can compare with how the code looked back in the
days when I entered this project that writing an entire library like libssh2
and make it non-blocking in nature without using non-blocking sockets is
really tricky and it certainly was not done this way in the past. With
blocking sockets we can never do recv() or send() without a preceeding
select() or poll() to make sure the socket is fine (and yet there is the odd
chances they can still block due to kernel-details).
So what I come back to over and over again in this discussion:
I DEMAND a non-blocking libssh2 API. To offer a true non-blocking API to the
world, it is a lot easier and less messy by setting the actual underlying
socket to non-blocking to never risk that it blocks.
If someone thinks I'm wrong at any of these points, it's perfectly fine and
all, but until someone brings code that proves they can offer a non-blocking
API with blocking underlying sockets and still have the internal code look
decent it's only talk and talk is really lightweight against working code.
--
/ daniel.haxx.se
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
