3 ms·

The way you are using the term "blocking" is non-standard and not that useful. You are calling the syscall "blocking" just because it performs its work inline

The way you are using the term "blocking" is non-standard and not that useful. You are calling the syscall "blocking" just because it performs its work inline (in this case, copying a kernel buffer into a user-space buffer). By this definition, every syscall is blocking, even aio_read() because even aio_read() performs some work inline (namely enqueing a read request). In common usage, an I/O operation is considered "blocking" if the system call does not return until data is available. If on the other hand you set O_NONBLOCK on a fd, you will get EAGAIN when no data is available, so clearly that is the accepted meaning of "nonblocking."

rdtsc 16y ago
> You are calling the syscall "blocking" just because it performs its work inline. Yes because there is _another_ mode of IO where it doesn't have to do that. So the reason that is called "blocking" is because there is another mode of operation (albeit it is exotic) where the process does not block while performing IO -- the kernel reads/writes the data on behalf of the process. If this second mode of performing IO did not ever exist you could just interchange arbitrarily asynchronous and non-blocking as synonyms. Since you didn't bother reading the link I posted here is the basic matrix of IO operations: Synchronous Asynchronous Blocking read/write select/[e]poll Non-Blocking O_NONBLOCK+E_AGAIN aio_* There has been talk and various attempt at implementing aio_* style IO for network sockets on Linux, but nothing good so far. > Even aio_read() performs some work inline (namely enqueing a read request). Enqueuing the read request is not the same as actually copying gigabytes or terabytes of data from disk where the actual work is performed.
- tptacek 16y ago
  I think the DeveloperWorks article you've cited is simply wrong, and that's sent you into a tailspin. Select and poll aren't "ways to implement asynchronous blocking I/O". I think you'll find these links more helpful than the misleading one you've been using. http://www.circlemud.org/~jelson/software/fusd/docs/node36.html http://www.circlemud.org/~jelson/software/fusd/docs/node36.h... http://people.freebsd.org/~hmp/stuff/docs/freebsd_kse.pdf http://people.freebsd.org/~hmp/stuff/docs/freebsd_kse.pdf I could always be wrong about this stuff; maybe I'm the one with the broken semantics. But I'm pretty sure I'm not.
- haberman 16y ago
  > Since you didn't bother reading the link I posted here is the basic matrix of IO operations. Actually I did. You are misinterpreting what it is saying. The reason it is calling the select() model "blocking" is because you block during the select(), not because the read() itself is blocking. This is also non-standard usage: most people wouldn't refer to a select()-based loop as blocking I/O, because a program generally only calls select() when it has nothing else to do but service I/O, so the select() does not "block" the application.

rdtsc 16y ago

> You are calling the syscall "blocking" just because it performs its work inline. Yes because there is _another_ mode of IO where it doesn't have to do that. So the reason that is called "blocking" is because there is another mode of operation (albeit it is exotic) where the process does not block while performing IO -- the kernel reads/writes the data on behalf of the process. If this second mode of performing IO did not ever exist you could just interchange arbitrarily asynchronous and non-blocking as synonyms. Since you didn't bother reading the link I posted here is the basic matrix of IO operations: Synchronous Asynchronous Blocking read/write select/[e]poll Non-Blocking O_NONBLOCK+E_AGAIN aio_* There has been talk and various attempt at implementing aio_* style IO for network sockets on Linux, but nothing good so far. > Even aio_read() performs some work inline (namely enqueing a read request). Enqueuing the read request is not the same as actually copying gigabytes or terabytes of data from disk where the actual work is performed.

tptacek 16y ago
I think the DeveloperWorks article you've cited is simply wrong, and that's sent you into a tailspin. Select and poll aren't "ways to implement asynchronous blocking I/O". I think you'll find these links more helpful than the misleading one you've been using. http://www.circlemud.org/~jelson/software/fusd/docs/node36.html http://www.circlemud.org/~jelson/software/fusd/docs/node36.h... http://people.freebsd.org/~hmp/stuff/docs/freebsd_kse.pdf http://people.freebsd.org/~hmp/stuff/docs/freebsd_kse.pdf I could always be wrong about this stuff; maybe I'm the one with the broken semantics. But I'm pretty sure I'm not.
haberman 16y ago
> Since you didn't bother reading the link I posted here is the basic matrix of IO operations. Actually I did. You are misinterpreting what it is saying. The reason it is calling the select() model "blocking" is because you block during the select(), not because the read() itself is blocking. This is also non-standard usage: most people wouldn't refer to a select()-based loop as blocking I/O, because a program generally only calls select() when it has nothing else to do but service I/O, so the select() does not "block" the application.