Bryan Olson wrote: >Looking at the code for the existing _fileobject's read method, it >will loose data it has already read if a socket.recv() call raises >an exception. The function keeps buffers in a local variable that >will be lost if an exception exits the scope. That much could be >fixed with a try...finally. Other methods have similar problems.
Just as I thought. Thanks for being my extra set of eyes. >>I wanted to use file-like objects with socket timeouts, so I ended up >>writing my own replacement for socket._fileobject. I'd appreciate it >>if someone could either explain to my why my new class was unnecessary, >>or else encourage me to contribute it as a patch to the socket module. > >Sure, fix it. Yeah, I'll give it some more thought. >A harder problem is that it doesn't play nice with select(). I guess you mean that since _fileobject.read() calls recv() multiple times, the second and later calls might block even if select() said the socket was readable. That should be fixable by catching EAGAIN / EWOULDBLOCK and returning early, shouldn't it? This idea seems consistent with the normal file object's read() method docs, which say, "in non-blocking mode, less data than what was requested may be returned." Making write() and flush() friendly in non-blocking mode might be at little trickier. -- http://mail.python.org/mailman/listinfo/python-list
