How would you explain a simple mortal about blocking IO and non-blocking IO? I've found these concepts are not very clear among many of us programmers.
+3
A:
Blocking I/O means that the program execution is put on hold while the I/O is going on. So the program waits until the I/O is finished and then continues it's execution. In non-blocking I/O the program can continue during I/O operations.
Lex
2009-09-26 08:04:33
... and is the notified via a callback when the IO operation is finished. This forces you to design your programs differently, but will make them perform a lot better.
Vinko Vrsalovic
2009-09-26 08:05:58
A:
simply said .. the non blocking i/o (Asynchronous) allows other operations to be carried out while it does its thing and blocking i/o would block other operations
Sabeen Malik
2009-09-26 08:04:50
+2
A:
It's a concurrency issue. In the normal case, after an OS kernel receives an I/O op from a user program, that program does not run again until the I/O operation completes. Other programs typically get scheduled in the meantime.
This solves lots of little problems. For example, how does a program know how many bytes were read unless the I/O is complete when the read(2) returns? How does it know if it can reuse a write(2) buffer if the operation is still in progress when write(2) returns? Obviously, a more complex interface is needed for truely asynchronous I/O.
Ultimately it comes down to:
- I/O happens synchronously with respect to the program, by blocking the program until I/O is finished
- I/O is merely scheduled by a system call, and some notification mechanism exists to communicate the real result
- There is a compromise where I/O ops simply fail if they can't be completed immediately. This is the more common use of "non-blocking" I/O in practice.
The whole issue is complicated moreover by the effort to schedule multithreaded programs when I/O could conceivably block only one thread, but that's a different question...
DigitalRoss
2009-09-26 08:11:30