why does socket.makefile require non-blocking mode?
The socket.makefile() docs say, "the socket must be in blocking mode." I don't see any explanation of why blocking mode is required, and I'm not sure whether that means timeout mode is forbidden as well. Can someone clarify this? 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. Cheers, Forest -- http://mail.python.org/mailman/listinfo/python-list
Re: why does socket.makefile require non-blocking mode?
On Sat, 29 Mar 2008 08:18:23 -0300, Guilherme Polo wrote: >I don't know why you think timeout is forbidden too, it is not. I can't tell for sure whether it is or isn't, because of this language in the socket module docs: "s.settimeout(0.0) is equivalent to s.setblocking(0); s.settimeout(None) is equivalent to s.setblocking(1)." >>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 me why my new class was unnecessary, >>or else encourage me to contribute it as a patch to the socket module. > >It looks like to be unnecessary. I'm hoping for a more definitive answer than "looks like", but thank you just the same. My main concern is this: A brief look at the existing socket._fileobject shows that its read() method calls recv() in a loop, appending to a temporary buffer on each pass, and finally returning the buffer when recv() gets no more data. It looks to me like a socket timeout exception would cause that loop to exit without saving the data collected in earlier passes. In other words, data loss on recv() timeout. If someone more familiar with socket._fileobject can point out a reason this cannot happen (perhaps I've missed something) I'll be satisfied. Otherwise, I think my rewritten class has value. -- http://mail.python.org/mailman/listinfo/python-list
Re: why does socket.makefile require non-blocking mode?
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
