> From: Igor Sysoev [mailto:[EMAIL PROTECTED] > Subject: RE: aio_connect ? > > On Wed, 20 Oct 2004, Christopher M. Sedore wrote: > > > > While the developing my server nginx, I found the POSIX aio_* > > > operations > > > uncomfortable. I do not mean a different programming style, I mean > > > the aio_read() and aio_write() drawbacks - they have no > scatter-gather > > > capabilities (aio_readv/aio_writev) and they require too many > > > syscalls. > > > E.g, the reading requires > > > *) 3 syscalls for ready data: aio_read(), aio_error(), > aio_return() > > > *) 5 syscalls for non-ready data: aio_read(), aio_error(), > > > waiting for notification, then aio_error(), aio_return(), > > > or if timeout occuired - aio_cancel(), aio_error(). > > > > This is why I added aio_waitcomplete(). It reduces both > cases to two > > syscalls. > > As I understand aio_waitcomplete() returns aiocb of any complete AIO > operation but I need to know the state of the exact AIO, > namely the last > aio_read().
Correct, it won't poll, but what state can you get from calling aio_error() that you don't already know from aio_waitcomplete(). The operation has either completed (successfully or unsuccessfully) or it hasn't. If it hasn't you haven't "gotten it back" via aio_waitcomplete, and if it has, you did. I may be missing something, but how does aio_error() tell you something that you don't already know? > I use kqueue to get AIO notifications. If AIO operation would fail > at the start, will kqueue return notificaiton about this operation ? I don't think so--IIRC, if you have a parameter problem or the operation can't be queued, you'll get an error return from aio_read and no kqueue result. If it is queued, you'll get a kqueue notification. -Chris _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
