--bg08WKrSYDhXBjb5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 01, 2007 at 10:22:33AM -0800, jonathan@dsg.stanford.edu wrote:
>=20
> In message <20070301172837.GA22343@netbsd.org>Bill Stouder-Studenmund wri=
tes
>=20
> >In terms of select, the disk is always ready.
>=20
> But of course. That's how it's always been defined.
>=20
> 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).

Well, for read, the moment something's not in cache, you block. And as you=
=20
note, writes are problematic.

> >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=3D20
> >struct then gets destroyed.
>=20
> 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?

As I note below, I can be off in terms of standards. Everything I said=20
equally applies if we use different system calls. Then rather than AIO=20
mode being a function of the fd, it's a function of the call.

> >I could have stuff wrong in therms of standards compliance, but I think=
=3D20
> >I think NetBSD will greatly benefit from AIO, regardless of the threadin=
g=3D
> >model.
>=20
> 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=
 :-/.

Continuations are why I described it as I did, but a pool of threads would=
=20
work well too. And it'd probably be easier in the short term.

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

Take care,

Bill

--bg08WKrSYDhXBjb5
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFF5x78Wz+3JHUci9cRAiwZAJ9LV4AlIwlk7/+/j6+E7SlVORIeWACfYG4b
BaHyh9PlGP4Ynh4Z63AU9qw=
=o79p
-----END PGP SIGNATURE-----

--bg08WKrSYDhXBjb5--