Henrik Nordstrom 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.
If you read() or write() to a `slow' descriptor (pipe, socket,
character device), and it can't provide/accept all of the data, it
will provide/accept what it can, and return a short count.
> 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.
You shouldn't need to make the descriptor non-blocking; read() and
write() should only block if they can't provide/accept *any* data (or
less than the `water-mark' if you are using setsockopt(SO_RCVLOWAT) et
al), otherwise they should return immediately with a short count.
> 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.
File I/O never `blocks'; read() or write() to a file are always deemed
to complete `immediately' (although NFS filesystems can cause
`immediately' to mean something other than its typical meaning).
This applies to O_NONBLOCK, ioctl(FIONREAD), ..., and not just
select().
--
Glynn Clements <[EMAIL PROTECTED]>
