Flush stdin

Chris Angelico rosuav at gmail.com
Wed Oct 22 08:23:15 CEST 2014


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



More information about the Python-list mailing list