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 <>
If you look at, 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 

Seeing your comment, I realize that 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 

In all the cases in the, 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 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 

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.
Date User Action Args
2008-11-28 09:35:44kristjan.jonssonsetrecipients: + kristjan.jonsson, gvanrossum, gregory.p.smith
2008-11-28 09:35:44kristjan.jonssonsetmessageid: <>
2008-11-28 09:35:43kristjan.jonssonlinkissue4448 messages
2008-11-28 09:35:42kristjan.jonssoncreate