[Python-Dev] socket.c, _rbufsize (original) (raw)
Gregory P. Smith greg at krypto.org
Thu Nov 27 21:58:31 CET 2008
- Previous message: [Python-Dev] socket.c, _rbufsize
- Next message: [Python-Dev] Python 2.6/3.0, IEEE 754 floating point semantics and S60
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I've created http://bugs.python.org/issue4448 to track this issue.
On Thu, Nov 27, 2008 at 6:50 AM, Kristján Valur Jónsson < kristjan at ccpgames.com> wrote:
I came across this in socket.c:
# rbufsize is the suggested recv buffer size. It is strictly # obeyed within readline() for recv calls. If it is larger than # defaultbufsize it will be used for recv calls within read().
What I worry about is the readline() case. Is there a reason why we want to strictly obey it for that function? Note that in the documentation for fileobject.read() it says: # Use max, disallow tiny reads in a loop as they are very inefficient. The same argument surely applies for readline(). The reason I am fretting about this is that httplib.py (and therefore xmlrpclib.py) specify bufsize=0 when createing their socket fileobjects, presumably to make sure that write() operations are not buffered but flushed immediately. But this has the side effect of setting the rbufsize to 1, and so readline() calls become very slow. I suggest that readline() be made to use at least defaultbufsize, like read(). Any thoughts? Cheers, Kristján
Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/greg%40krypto.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20081127/0549991c/attachment.htm>
- Previous message: [Python-Dev] socket.c, _rbufsize
- Next message: [Python-Dev] Python 2.6/3.0, IEEE 754 floating point semantics and S60
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]