From owner-freebsd-hackers Sun Aug 3 13:44:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA16015 for hackers-outgoing; Sun, 3 Aug 1997 13:44:03 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA15992; Sun, 3 Aug 1997 13:43:55 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA02183; Sun, 3 Aug 1997 13:43:22 -0700 From: Terry Lambert Message-Id: <199708032043.NAA02183@phaeton.artisoft.com> Subject: Re: non-blocking file i/o To: gpalmer@FreeBSD.ORG (Gary Palmer) Date: Sun, 3 Aug 1997 13:43:22 -0700 (MST) Cc: dyson@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: <22934.870566300@orion.webspan.net> from "Gary Palmer" at Aug 2, 97 07:58:20 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > The AIO code is a standard (nice) way to implement database I/O. > > Will it allow the write() to complete more quickly and actually be > async, or just provide a callback to the program when the OS finally > commits the data to disk? For INN's DBZ, I don't think the callback > matters at all. The time it takes to do the write() is what is > important in this case. It should allow the write to be queued. You will have to wait for completion to verify that it actually took place. Async I/O is a concurrency boost, if your software is correctly written. If your software is not correctly written, then you will sit in an aiowait() waiting for the write completion, instead of queueing the next write, like you should be doing. Exactly what do you think an asynchronous wrute should do, if not queue the write for servicing, and return immediately? Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.