Flush stdin
Chris Angelico
rosuav at gmail.com
Wed Oct 22 02:23:15 EDT 2014
More information about the Python-list mailing list
Wed Oct 22 02:23:15 EDT 2014
- Previous message (by thread): Flush stdin
- Next message (by thread): Flush stdin
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Wed, Oct 22, 2014 at 4:38 PM, Marko Rauhamaa <marko at pacujo.net> wrote: > Dan Stromberg <drsalists at gmail.com>: > >> On Mon, Oct 20, 2014 at 9:41 PM, Marko Rauhamaa <marko at pacujo.net> wrote: >>> Nagle affects the communication between the peer OS kernels and isn't >>> directly related to anything the application does. >> >> Actually, Nagle can cause two or more small packets to be merged, >> which is something an application must be able to deal with, because >> they could show up in the receiving application as one or more (but >> anyway: fewer) merged recv()'s. > > Packets have barely anything to do with TCP sockets since they provide > an octet stream abstraction. TCP does abstract over the individual packets, but they are still important. >> Of course, but who's doing one byte per second? You and I in our >> tests, and perhaps some application developers with remarkably >> undemanding I/O. That doesn't really mean we should _recommend_ a >> series of os.read(0, 1)'s. > > No, here's my statement: if you need to process input as soon as it > becomes available, you can't use sys.stdin. Instead, you need to use > os.read(). > > You typically supply os.read() with a buffer of a kilobyte or more. Key > is, os.read() returns right away if fewer bytes are available. Then your statement is false. Maybe it's not *efficient* if you always use sys.stdin.read(1), but you certainly can do it. It's not that you *need to* use something else. ChrisA
- Previous message (by thread): Flush stdin
- Next message (by thread): Flush stdin
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list