poll, select and "would block"

Question

I am learning about poll, select and similar functions and I am constantly bothered by the statement "would block" (which shows up both on the book I am reading about building drivers for Linux and also on the man pages of poll and select). I don't really get this. What would be blocked? The process which is reading/writing to a file descriptor? The reading/writing operation itself, in the sense that no other process would be able to read/write to that file when the current process is reading/writing on it?

I am sorry if this is a stupid question but I am having a difficult time finding the answer for this question anywhere.

jeff.vanvoorst · Accepted Answer · 2012-09-24T16:01:32.667

3

Would block means that the process making the system call would block (wait) until the system call returns. For example, if you ask your program to read a file, after issuing the read command, your program will wait (block) until the operating system performs the read and returns the results to your program.

With regards to multiple programs accessing the same file, multiple processes can read the same file. However, you can (and usually will) have race conditions when one or more processes is writing to a file that has one or more processes reading the same file. In other words, blocking is with regards to a single process accessing a file, and gives no guarantees about the order of operations (e.g. reads and writes) between two processes accessing the same file. (I was thinking about files for some reason; the read/write characteristics of pipes and sockets differ significantly from those of files on a filesystem).

edited Sep 24 '12 at 16:01

answered Sep 24 '12 at 15:49

jeff.vanvoorst

129
6

Although I mentioned files above, the primary uses for poll, select, etc. are for file like objects such as sockets and pipes. A process A that tries to read from a socket will block (wait) until another process writes to that socket. However, A's blocking on read does not affect the writing or reading from that socket by any other process (i.e. other processes can still read and write to that socket even though A is blocked on a read from that socket). – jeff.vanvoorst Sep 24 '12 at 16:00
Clearly, I am thinking too much about ZeroMQ. Sockets and pipes are between pairs of processes. – jeff.vanvoorst Sep 24 '12 at 16:07

score 2 · Answer 2 · answered Sep 24 '12 at 16:05

In addition to jeffs correct answer:

You can, however, use most of those system calls in a nonblocking way if you open the corresponding filedescriptor in nonblocking mode (O_NONBLOCK). The the call will always immediately return, but if it fails it returns with EWOULDBLOCK in errno (and no valid data) and you will need to handle this by yourself in your application or driver.

score 2 · Answer 3 · edited May 23 '17 at 12:06

Let me put it another way.

1) Normal I/O is "blocking". You issue a "read", and your program "waits" until the data arrives or until an error (or timeout) occurs.

2) Non-blocking I/O is "different". You need some way to tell whether or not you're "done".

3) For "reads", EWOULDBLOCK says "there isn't any data". It's saying "if this were 'normal I/O', then I'd block".

4) For "writes", EWOULDBLOCK is saying "the first buffer hasn't been completely sent and acknowledged yet - you might want to hold off before you send anything else."

Two links:

poll, select and "would block"

3 Answers3