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

[Donovan Baarda]

On Tue, 2005-03-22 at 12:49 +1200, Greg Ewing wrote:
> Donovan Baarda wrote:
> 
> > Consider the following. This is pretty much the only way you can use
> > popen2 reliably without knowing specific behaviours of the executed
> > command;
> > 
>  > ...
> >   fcntl.fcntl(child_in, fcntl.F_SETFL, flags | os.O_NONBLOCK) # \
> > ...			      # /
> >   fcntl.fcntl(child_out, fcntl.F_SETFL, flags | os.O_NONBLOCK)# \
> 
> I still don't believe you need to make these non-blocking.
> When select() returns a fd for reading/writing, it's telling
> you that the next os.read/os.write call on it will not block.
> Making the fd non-blocking as well is unnecessary and perhaps
> even undesirable.

Yeah... For some reason I had it in my head that os.read/os.write would
not do partial/incomplete reads/writes unless the file was in
non-blocking mode.

> > For 1) and 2), note that popen2 returns file objects, but as they cannot
> > be reliably used as file objects, we ignore them and grab their
> > fileno(). Why does popen2 return file objects if they cannot reliably be
> > used?
> 
> I would go along with giving file objects alternative read/write
> methods which behave more like os.read/os.write, maybe called
> something like readsome() and writesome(). That would eliminate
> the need to extract and manipulate the fds, and might make it
> possible to do some of this stuff in a more platform-independent
> way.

The fact that partial reads/writes are possible without non-blocking
mode changes things a fair bit. Also, the lack of fnctl support in
Windows needs to be taken into account too.

I still think the support for partial reads in non-blocking mode on
file.read() is inconsistent with the absence of partial write support in
file.write(). I think this PEP still has some merit for cleaning up this
inconsistency, but otherwise doesn't gain much... just adding a return
count to file.write() and clearing up the documented behaviour is enough
to do this.

The lack of support on win32 for non-blocking mode, combined with the
reduced need for it, makes adding a "setblocking" method undesirable.

I don't know what the best thing to do now is... I guess the
readsome/writesome is probably best, but given that os.read/os.write is
not that bad, perhaps it's best to just forget I even suggested this
PEP :-)

-- 
Donovan Baarda <abo at minkirri.apana.org.au>
http://minkirri.apana.org.au/~abo/