[Python-Dev] Darwin's realloc(...) implementation never shrinks allocations (original) (raw)

bacchusrx bacchusrx at skorga.org
Mon Jan 3 21:23:50 CET 2005

On Thu, Jan 01, 1970 at 12:00:00AM +0000, Tim Peters wrote:

Is there any known case where Python performs poorly on this OS, for this reason, other than the "pass giant numbers to recv() and then shrink the string because we didn't get anywhere near that many bytes" case?

[...] I agree the socket-abuse case should be fiddled, and for more reasons than just Darwin's realloc() quirks. [...] Yes, in the socket-abuse case, where the program routinely malloc()s strings millions of bytes larger than the socket can deliver, it would obviously help. That's not typically program behavior (however typical it may be of that specific app).

Note that, with respect to http://python.org/sf/1092502, the author of the (original) program was using the documented interface to a file object. It's _fileobject.read() that decides to ask for huge numbers of bytes from recv() (specifically, in the max(self._rbufsize, left) condition). Patched to use a fixed recv_size, you of course sidestep the realloc() nastiness in this particular case.

bacchusrx.

More information about the Python-Dev mailing list