In message <20070301172837.GA22343@netbsd.org>Bill Stouder-Studenmund writes

>In terms of select, the disk is always ready.

But of course. That's how it's always been defined.

But there are apps (or programming styles) where it's incredibly
useful to find the point at which an I/O read is going to block.
Right now, how much can I read() without blocking?  One byte? 512? 1k?
8K? 64k?  1M?  I've often wanted a way to do a kqueue-like request to
ask that.  Asking for writes would be even better, but that brings up
all sorts of overcommit issues. (buffer space avaiable now may not be
available by the time the requesting process tries to write() into it).


>A file descriptor is in aio mode. A write or read comes in. The kernel
>allocates an aio structure, copies in info from userland (like addresses,
>etc for a read), fires off the i/o, and returns to userland. When the i/o
>completes, the aio gets fed to a kevent to pass to userland. The aio=20
>struct then gets destroyed.

Is there any "aio mode"? I thought AIO ops should be issuable on any
suitable FD.  Does POSIX require the file descriptor to be in
non-blocking mode?


>I could have stuff wrong in therms of standards compliance, but I think=20
>I think NetBSD will greatly benefit from AIO, regardless of the threading=
>=20
>model.

Well, the typical way to implement AIO is to have a pool of kernel
threads. Grab a kernel thread, issue the i/o, using the kernel thread
as the thread which blocks until the I/O is complete.  Then the kernel
thread posts completion to the AIO subsystem, which passes appropriate
status, signal info, etc. to the requesting thread.  Hmmmm, continuations :-/.

[[Looking ahead, I see someone is already working on AIO for NetBSD.]]