On Mon, 18 Nov 2013 17:14:21 +0100
Antoine Pitrou <solip...@pitrou.net> wrote:
> On Sun, 17 Nov 2013 23:53:09 -0600
> Tim Peters <tim.pet...@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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
