In article <[EMAIL PROTECTED]>, Greg Ewing <[EMAIL PROTECTED]> wrote:
> 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). You can test this on your platform, I will append a 9 line program. For me, fileobject.read blocks until all the requested data can be returned. > 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. Yes, this looks right to me, but I think we're talking about os.read(), not fileobject.read(). > 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. Exactly. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list