On Mon, 21 Mar 2005, Donovan Baarda wrote: > > I don't agree with that. There's no need to use non-blocking > > I/O when using select(), and in fact things are less confusing > > if you don't. > > You would think that... and the fact that select, popen2 etc all use > file objects encourage you to think that. However, this is a trap that > can catch you out badly. Check the attached python scripts that > demonstrate the problem. This is no "trap". When select() indicates that you can write or read, it means that you can write or read at least one byte. The .read() and .write() file methods, however, always writes and reads *everything*. These works, basically, just like fread()/fwrite(). > The only ways to ensure that a select process does not block like this, > without using non-blocking mode, are; > > 1) use a buffer size of 1 in the select process. > > 2) understand the child process's read/write behaviour and adjust the > selector process accordingly... ie by making the buffer sizes just right > for the child process, 3) Use os.read / os.write. > > >>The read method's current behaviour needs to be documented, so its actual > > >>behaviour can be used to differentiate between an empty non-blocking read, > > >>and EOF. This means recording that IOError(EAGAIN) is raised for an empty > > >>non-blocking read. > > > > Isn't that unix-specific? The file object is supposed to > > provide a more or less platform-independent interface, I > > thought. > > I think the fread/fwrite and read/write behaviour is posix standard and > possibly C standard stuff... so it _should_ be the same on other > platforms. Sorry if I've misunderstood your point, but fread()/fwrite() does not return EAGAIN. /Peter Åstrand <astrand at lysator.liu.se>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4