This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gregory.p.smith
Recipients gregory.p.smith
Date 2008-11-27.20:57:08
SpamBayes Score 0.00058394286
Marked as misclassified No
Message-id <1227819431.06.0.748604307582.issue4448@psf.upfronthosting.co.za>
In-reply-to
Content
....
From Kristján Valur Jónsson (kristjan at ccpgames.com) on python-dev:

 http://mail.python.org/pipermail/python-dev/2008-November/083724.html
....

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
        # default_bufsize 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?
History
Date User Action Args
2008-11-27 20:57:11gregory.p.smithsetrecipients: + gregory.p.smith
2008-11-27 20:57:11gregory.p.smithsetmessageid: <1227819431.06.0.748604307582.issue4448@psf.upfronthosting.co.za>
2008-11-27 20:57:10gregory.p.smithlinkissue4448 messages
2008-11-27 20:57:09gregory.p.smithcreate