Does python's sys.stdin.read() block?

Question

I'm adapting this Django management command for my own purposes. The script is a simple while-loop daemon that reads from sys.stdin (line 152, in command.handle()) according to a protocol and writes results to sys.stdout.

I would expect sys.stdin.read() to block until it receives something, but I find that when I run this script, it eats up 100% CPU before any data has been sent or received.

Does sys.stdin.read(n) block?
If not, how can I make this daemon more polite?
Is time.sleep(s) safe to use, or will I miss input or be slow to respond?

So, in summary, I was Doing It Wrong, running this as an upstart daemon when it needed to be managed by the ejabberd server itself. The larger question, "Does sys.stdin.read() block?" is still interesting, though. :) — David Eyk, Dec 07 '10 at 20:21
I still have no idea why the daemonized version was running the CPU so hot, and I probably never will. — David Eyk, Dec 07 '10 at 20:24

score 2 · Accepted Answer · edited May 23 '17 at 10:31

2

By default, sys.stdin.read() and sys.stdin.read(n) are blocking calls. I would assume the consumption of 100% CPU is actually attributable to streaming data into your script or some other behavior not cited here.

Upon looking at the help documentation for sys.stdin.read, I noticed this:

read(...)

read([size]) -> read at most size bytes, returned as a string.

If the size argument is negative or omitted, read until EOF is reached. Notice that when in non-blocking mode, less data than what was requested may be returned, even if no size parameter was given.

(Emphasis mine.)

This implies blocking mode is the default behavior, which is consistent with my experience. It also led me to track down similar questions on SO. Voila: Non-blocking read on a subprocess.PIPE in python

Good luck with your adaptation!

edited May 23 '17 at 10:31

Community

1
1

answered Dec 05 '10 at 02:50

MrGomez

23,788
45
72

It's actually 100% usage w/o receiving or outputting any data yet. I haven't hooked that part up yet. – David Eyk Dec 05 '10 at 19:21
Knowing for sure that it's a blocking call, and hearing the result of @icyrock.com's test, I'm guessing my problem lies elsewhere. – David Eyk Dec 05 '10 at 20:46
Yep. The problem was me. I still don't know why I was getting the high CPU usage, but now that I've set up my bridge correctly, everything works fine. – David Eyk Dec 05 '10 at 21:39

score 1 · Answer 2 · answered Dec 05 '10 at 02:15

1

It works OK on my machine (i.e. blocks with negligent CPU usage while it's reading) - can you check it from a simple command line script before? Also, I tested this within Linux, might be different on other platforms.

answered Dec 05 '10 at 02:15

icyrock.com

27,952
4
66
85

This suggests to me that there's another factor involved. Thanks for testing this! – David Eyk Dec 05 '10 at 19:21

score 0 · Answer 3 · answered Dec 05 '10 at 02:29

0

Is there a chance the stream has been closed (e.g. EOF was sent)?

answered Dec 05 '10 at 02:29

Karl Knechtel

62,466
11
102
153

No data has been sent yet, so no, I don't think there's a possibility of an EOF. – David Eyk Dec 05 '10 at 19:22

Does python's sys.stdin.read() block?

3 Answers3

Linked