Home Original page

[Python-Dev] Accepting PEP 3154 for 3.4?

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