non blocking read()

[Greg Ewing]

Donn Cave wrote:
> If we are indeed talking about a pipe or something that
> really can block, and you call fileobject.read(1024),
> it will block until it gets 1024 bytes.

No, it won't, it will block until *some* data is
available, and then return that (up to a maximum of
1024).

If the fd has just been reported by select() as ready
for reading, then something is there, so the first
read() call won't block. But if there was exactly
1024 bytes there, the second read() call *will* block,
because there are now 0 bytes available (which I think
is what an earlier poster was hinting at).

For this reason, if you have no way of knowing how
much data to expect in advance, it's better to avoid
making more than one read() call on a fd per select().
If you don't get a whole line (or whatever chunk you're
looking for), put what you've got into a buffer, and
go back to select(). When you've built up a complete
chunk in the buffer, process it. Keep in mind that
part of the next chunk may be in the tail of the
buffer, so be prepared to chop a chunk off the
beginning of the buffer and leave the rest for later.

Another possibility that's been suggested is putting
the fd into non-blocking mode. I wouldn't recommend
that; the last time I tried it (which was quite a long
time ago) select() and non-blocking I/O didn't mix
well. While it may be possible to get it to work, I
don't think you'd gain much. You need to understand
that there's no guaranteed relationship between the
chunks of data written to one end of a pipe or socket
and those returned by reading the other end. So you'd
still need to be prepared to buffer and re-chunk the
data. You'd end up doing all of what I outlined above,
with the extra complication of non-blocking I/O thrown
in. I don't see any advantage in it.

-- 
Greg Ewing, Computer Science Dept,
University of Canterbury,	
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg