Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #96967

Re: Lightwight socket IO wrapper

Date 2015-09-22 07:42 +1000
From Cameron Simpson <cs@zip.com.au>
Subject Re: Lightwight socket IO wrapper
References <CAPTjJmopC+xPx4ak084UP4oxOay7jKkK8ggQvAKcRFycAs9d7g@mail.gmail.com>
Newsgroups comp.lang.python
Message-ID <mailman.46.1442871863.28679.python-list@python.org> (permalink)

Show all headers | View raw


On 21Sep2015 18:07, Chris Angelico <rosuav@gmail.com> wrote:
>On Mon, Sep 21, 2015 at 5:59 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> Chris Angelico <rosuav@gmail.com>:
>>
>>> On Mon, Sep 21, 2015 at 4:27 PM, Cameron Simpson <cs@zip.com.au> wrote:
>>>> For sizes below 128, one byte of length. For sizes 128-16383, two bytes. And
>>>> so on. Compact yet unbounded.
>>>
>>> [...]
>>>
>>> It's generally a lot faster to do a read(2) than a loop with any
>>> number of read(1), and you get some kind of bound on your allocations.
>>> Whether that's important to you or not is another question, but
>>> certainly your chosen encoding is a good way of allowing arbitrary
>>> integer values.
>>
>> You can read a full buffer even if you have a variable-length length
>> encoding.
>
>Not sure what you mean there. Unless you can absolutely guarantee that
>you didn't read too much, or can absolutely guarantee that your
>buffering function will be the ONLY way anything reads from the
>socket, buffering is a problem.

I'm using buffered io streams, so that layer will be reading in chunks. Pulling 
things from that buffer with fp.read(1) is cheap enough for my use.

Cheers,
Cameron Simpson <cs@zip.com.au>

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread


Thread

Re: Lightwight socket IO wrapper Cameron Simpson <cs@zip.com.au> - 2015-09-22 07:42 +1000

csiph-web