Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #96967
| 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) |
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
Re: Lightwight socket IO wrapper Cameron Simpson <cs@zip.com.au> - 2015-09-22 07:42 +1000
csiph-web