Date: Mon, 1 Dec 1997 21:21:54 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: tlambert@primenet.com (Terry Lambert) Cc: toor@dyson.iquest.net, current@freebsd.org Subject: Re: FYI: usage of new AIO calls Message-ID: <199712020221.VAA08422@dyson.iquest.net> In-Reply-To: <199712020132.SAA28471@usr07.primenet.com> from Terry Lambert at "Dec 2, 97 01:32:08 am"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712020221.VAA08422>