From owner-freebsd-current Mon Dec 1 18:22:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA15558 for current-outgoing; Mon, 1 Dec 1997 18:22:18 -0800 (PST) (envelope-from owner-freebsd-current) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA15540 for ; Mon, 1 Dec 1997 18:22:10 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.7/8.8.8) id VAA08422; Mon, 1 Dec 1997 21:21:54 -0500 (EST) (envelope-from toor) From: "John S. Dyson" Message-Id: <199712020221.VAA08422@dyson.iquest.net> Subject: Re: FYI: usage of new AIO calls In-Reply-To: <199712020132.SAA28471@usr07.primenet.com> from Terry Lambert at "Dec 2, 97 01:32:08 am" To: tlambert@primenet.com (Terry Lambert) Date: Mon, 1 Dec 1997 21:21:54 -0500 (EST) Cc: toor@dyson.iquest.net, current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert said: > > Not to rain on anyone's parade, but I sort of just assumed that any > "AIO" implementation that was implemented as other than a generalized > async call gate mechanism (so that a cooperative kernel/user threading > scheduler could be built) would be implemented as a compatability API > for exising AIO mechanisms, and not some new invention. 8-(. Pretty > cleary, the new invention (just like Sun's invention) is less than > useful for socket I/O that needs to consider OOB data. Like the Telnet > protocol used on the control connection to an FTP server. > > I like the idea of adding list-based mechanisms, but at the very > least, the API consumed by existing software should probably be > supported (and probably not as wrappers, both for ABI and for > non-list-based performance considerations). For example, can't > pthreads from the MIT distribution use aio instead of select() > based "readability/writeability" testing for a significant performance > win? > You have to realize what my near term/long term goals are. Firstly, there is absolutely no reason that the threading mechanism has to be used. I am NOT using it for my main purpose -- that is RAW I/O. If there is any cause to, we can abstract the code for sockets or whatever. Each type of device needs a different kind of handler, and at that point, some kind of switch scheme would be appropriate. The code as commited proves a couple of things: 1) We can do the non-threaded approach. (physio type transfers.) 2) We can do the threaded approach. (non-physio type transfers.) Eventually, we can easily extend the code to avoid kernel threads, except in exceptional cases. I would greatly appreciate it if you would consult with me so that you can: 1) Know what spec's that I am using (which happen to be the *standard*) 2) Know a little about my strategy and reasoning. before criticizing the work. Think database... If we need to extend the code for sockets, I can do it in a day... -- John dyson@freebsd.org jdyson@nc.com