[Python-Dev] Draft PEP to make file objects support non-blocking mode.

Peter Astrand astrand at lysator.liu.se
Mon Mar 21 09:45:57 CET 2005

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>

More information about the Python-Dev mailing list