I think this is a question of building in flow control and back pressure. Consider the following two programs:

bmaurer@bmaurer-mbp ~ % cat print.py
from datetime import datetime
import time
while True:
  print(( datetime.now().strftime('%Y-%m-%d %H:%M:%S.%f') + "\n") * 1000)
  time.sleep(0.01)
bmaurer@bmaurer-mbp ~ % cat read.py
import sys
import time

for line in sys.stdin:
  print(line.strip())
  time.sleep(0.02)

Here's what happens when you run `(python3 print.py | python3 read.py) | uniq -c`
1000 2024-11-07 13:58:56.902309
   1
1000 2024-11-07 13:58:56.914864
   1
1000 2024-11-07 13:58:56.927435
   1
1000 2024-11-07 13:59:04.074071
   1
1000 2024-11-07 13:59:32.693990
   1
1000 2024-11-07 13:59:54.138414
   1
1000 2024-11-07 14:00:15.592981
   1
1000 2024-11-07 14:00:44.261028
   1
1000 2024-11-07 14:01:05.678402
   1
1000 2024-11-07 14:01:27.292877
   1
1000 2024-11-07 14:01:49.064790
   1

How does print.py know to pause for so long between the blocks of output so that it can keep up? Read.py only reads a limited buffer of data when it reads stdin. When print.py tries to write() to the file descriptor for stdout, there's only a limited buffer size. This means that those calls sall, causing the space between the timestamps. Note that the first three blocks complete quite quickly (they're all in the second 13:58:56), but after that there is spacing between them.

There's no "magic" rate limit here. Just a fixed buffer size.

I think ET needs to do something similar. If the client is not reading from the socket at the rate the server is producing it, we must eventually produce back pressure on the server.

Uh oh!

Flow Control #631

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions