[Python-Dev] Accepting PEP 3154 for 3.4? (original) (raw)

Antoine Pitrou solipsis at pitrou.net
Mon Nov 18 19:41:54 CET 2013

On Mon, 18 Nov 2013 17:14:21 +0100 Antoine Pitrou <solipsis at pitrou.net> wrote:

On Sun, 17 Nov 2013 23:53:09 -0600 Tim Peters <tim.peters at gmail.com> wrote: > > But I wonder why it isn't done with a new framing opcode instead (say, > FRAME followed by 8-byte count). I suppose that would be like the > "prefetch" idea, except that framing opcodes would be mandatory > (instead of optional) in proto 4. Why I initially like that: > > - Uniform decoding loop ("the next thing" always starts with an opcode).

But it's not actually uniform. A frame isn't a normal opcode, it's a large section of bytes that contains potentially many opcodes. The framing layer is really below the opcode layer, it makes also sense to implement it like that. (I also tried to implement Serhiy's PREFETCH idea, but it didn't bring any actual simplification) > When slinging 8-byte counts, some sanity-checking seems like a good idea ;-) I don't know. It's not much worse (for denial of service opportunities) than a 4-byte count, which already exists in earlier protocols.

Actually, now that I think of it, it's even better. A 2**63 bytes allocation is guaranteed to fail, since most 64-bit CPUs have a smaller address space than that (for example, x86-64 CPUs seem to have a 48 bits virtual address space).

On the other hand, a 2**31 bytes allocation may very well succeed, eat almost all the RAM and/or slow down the machine by swapping out.

Regards

Antoine.

More information about the Python-Dev mailing list