Glynn Clements wrote:
> Sure, but there's no point in using non-blocking I/O in this case. If
> you use select() to wait until the descriptor is ready, then the
> subsequent read() or write() is guaranteed not to block.
Not entirely true. It is guaranteed to be some data available or
possible to write some amount of data (or a error condition), but it is
not guaranteed that a read() or write() wouldn't block.
On most OS:es you can make other calls to query how much data that can
be read or written without blocking on some kinds of filedescriptors,
but the simplest and most portable design is to set the descriptor
non-blocking and simply read or write what's accepted.
> Non-blocking I/O is useful primarily when it is interleaved with
> something else, e.g. computation or blocking I/O.
There are other uses as well. The one I commonly come in contact with is
when you have one process that maintains a couple of hundred (or
thousands) TCP connections, interleaved with some minor processing. See
http://squid.nlanr.net/ for this specific application.
> There is seldom any point in using both select() and O_NONBLOCK. In
> fact some implementations of select() (although Linux' doesn't appear
> to be one of them) don't work correctly on non-blocking descriptors.
This use of non-blocking I/O is well documented (unfortunately I do not
have a good reference at hand), and does work on all known UNIX or UNIX
compatibles.
> In these cases, select() usually indicates that a read() or write()
> won't block (so it will always be true for a non-blocking descriptor),
> rather than indicating that the operation will `succeed'.
The only similar case I know of is when you try to use select() on disk
file descriptors, which is not supported by any known UNIX. It always
returns the descriptor as ready.
---
Henrik Nordstr�m
