Author kristjan.jonsson
Recipients gregory.p.smith, gvanrossum, kristjan.jonsson
Date 2008-11-28.09:35:42
SpamBayes Score 2.65658e-08
Marked as misclassified No
Message-id <1227864944.5.0.903589123933.issue4448@psf.upfronthosting.co.za>
In-reply-to
Content
If you look at http://bugs.python.org/issue4336, half of the proposed 
patch is an attempt to deal with this performance issue.  In the patch, 
we laboriously ensure that bufsize=-1 is passed in for for the xmlrpc 
client.

Seeing your comment, I realize that xmlrpclib.py also uses direct 
access to h._conn.sock (if present) and uses recv() on that.  In fact, 
that is the only place in the standard library where I can find this 
pattern.  Was that a performance improvement?  It is hard to see how 
bypassing buffered read with a manual recv() can significantly alter 
performance.

In all the cases in the test_xmlrpc.py, h._conn.sock is actually None 
because h._conn has been closed in HttpConnection.getresponse()  
Therefore, my patch continues to work.  However, I will fix that patch 
to cater to this strange special case.

However, please observe that since _fileobject.read() calls are always 
buffered, in general there is no way to safely mix read() and recv() 
calls, althought the recv() and readline() has been fudged to work.  
Isn´t this just a case of a wart in the standard lib that we ought to 
remove?

Here is a suggestion:
1) document why readline() observes 0 buffering (to enable it to be 
used as a readline() utility tool on top of vanilla socket recv()
2) stop doing that in xmrlrpclib and use default buffering.
History
Date User Action Args
2008-11-28 09:35:44kristjan.jonssonsetrecipients: + kristjan.jonsson, gvanrossum, gregory.p.smith
2008-11-28 09:35:44kristjan.jonssonsetmessageid: <1227864944.5.0.903589123933.issue4448@psf.upfronthosting.co.za>
2008-11-28 09:35:43kristjan.jonssonlinkissue4448 messages
2008-11-28 09:35:42kristjan.jonssoncreate