Re: Why is non blocking desirable?

[Thomas Stover]

There are three related but slightly different issues. A socket/fd may 
or may not be "ready", and a socket/fd operation may or may not "block". 
A blocking synchronous call always returns after it completes. That may 
be very fast if the operation is "ready", or very slow (as in possibly 
waiting indefinitely) if the operation is not ready. That is why 
select() enters the picture, to find out who is ready for what. A 
socket/fd set to non-block should always return with an error if the 
operation is not ready, even if we didn't first test with select(). The 
next issue is that even though we normally think of a "ready" operation 
as "fast", it can still be slow-ish, and is always slower than returning 
right away and informing the process of the operation's completion at a 
later time asynchronously. For instance writing to disk may be a ready 
operation, yet still takes a while. That being said, just setting 
something to non-blocking is not the same thing as asynchronous IO. 
Asynchronous IO is not portable and also not always necessary. On the 
other hand, in my experience blocking with select(), is essentially the 
same thing as non blocking with select(). Now in some circles (Java, 
windows, etc) the terms non-blocking and asynchronous are used 
differently than in posix sockets. If I am confused, I would love to 
informed.

_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel