On Wed, 6 Sep 2017 09:06:53 +1200, Peter Reutemann wrote:

'... support for non-blocking buffered I/O operations to improve asynchronous I/O support...'

In the old days of DEC’s VMS, I/O dispatching was entirely separate from process dispatching. In other words, all I/O was asynchronous, and you had three ways to tell when an I/O operation had completed: it filled in a completion status block, set an event flag, or invoked an “asynchronous system trap” (AST) callback routine that you specified. Or any combination of the three. The kernel offered convenience wrapper routines for “synchronous” I/O, but all they did was make the asynchronous call, then block the process while waiting for it to complete. In the Unix world, on the other hand, all I/O was originally synchronous: if you wanted a process to run without blocking while I/O was in progress, you had to spawn multiple processes. This was supposed to work fine, because creating processes was cheaper in the Unix world than the VMS world. (Ah, but what happens if the process is interrupted by a signal while waiting for the I/O to complete? <https://www.jwz.org/doc/worse-is-better.html>) But it turned out that wasn’t enough. So threading was added in the 1990s. But even that wasn’t enough. So now Linux is slowly reintroducing the concept of asynchronous I/O. Which means they have to go through all the assumptions that are currently tying I/O dispatching and process dispatching together, and separate them. Seems this is going to take a while...