From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 05:52:47 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79FFD16A4CE for ; Thu, 21 Oct 2004 05:52:47 +0000 (GMT) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB61943D4C for ; Thu, 21 Oct 2004 05:52:46 +0000 (GMT) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id i9L5qjis091634; Thu, 21 Oct 2004 09:52:45 +0400 (MSD) (envelope-from is@rambler-co.ru) Date: Thu, 21 Oct 2004 09:52:45 +0400 (MSD) From: Igor Sysoev X-X-Sender: is@is.park.rambler.ru To: "Christopher M. Sedore" In-Reply-To: <32A8B2CB12BFC84D8D11D872C787AA9A058EE914@EXCHANGE.forest.maxwell.syr.edu> Message-ID: <20041021093817.J17688@is.park.rambler.ru> References: <32A8B2CB12BFC84D8D11D872C787AA9A058EE914@EXCHANGE.forest.maxwell.syr.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org cc: "Ronald F. Guilmette" Subject: RE: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 05:52:47 -0000 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. Yes, aio_waitcomplete() can be used as the single waiting point. But then I can not accept() connetions. How could I learn about the new connections ? > > 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? With aio_error() I may (and even have to) pass aiocb of the wanted operation. aio_waitcomplete() returns aiocb of any operation. If I have several operations there may be the race condition. > > 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. Well, so I may not call aio_error() just after aio_read()/aio_write(). However, I can not use aio_waitcomplete() instead of aio_error()/aio_return() pair after kevent() reports the completetion. Igor Sysoev http://sysoev.ru/en/