non-blocking disk i/o

[<don...@is...>]

Hoehle, Joerg-Cyril writes:
 > Hi,
 > 
 > there was a thread here about blocking i/o not working with disks,
 > only with sockets. I remember having read something about this
 > issue somewhere. I seem to remember that only FreeBSD would obey
 > non-blocking i/o for disk files.

I'm happy to see confirmation of that observation.

 > All I found now is:
 > http://www.kegel.com/c10k.html

Sounds like an asynchronous IO interface would be a good addition to
some future version of clisp.  That would be especially useful for
output, since you know how much you want to send. 

 > "An important bottleneck in this method is that read() or
 > sendfile() from disk blocks if the page is not in core at the
 > moment; setting nonblocking mode on a disk file handle has no
 > effect. Same thing goes for memory-mapped disk files."

This tends to support my theory that the reason it doesn't work is
that paging is not considered to be a case of blocking.

At the moment I'm happy with non-blocking IO to sockets.
That seems to provide (just my impression, no measurement implied)
about 90% of the possible performance for network servers.
If it worked for disk I'd be only about 10% happier.

Asynchronous IO and for that matter multiple threads (I only wish)
actually seem worse to me in the sense that they make scheduling
decisions which the programmer no longer controls, and which he
probably doesn't even understand.  I'd at least like to know how these
are made in order to decide whether I'd rather do it myself.