Date: Fri, 5 Mar 1999 00:38:46 -0500 (EST) From: "John S. Dyson" <dyson@iquest.net> To: hasty@rah.star-gate.com (Amancio Hasty) Cc: tlambert@primenet.com, dyson@iquest.net, dick@tar.com, jplevyak@inktomi.com, hackers@FreeBSD.ORG Subject: Re: lockf and kernel threads Message-ID: <199903050538.AAA20475@y.dyson.net> In-Reply-To: <199903050521.VAA56233@rah.star-gate.com> from Amancio Hasty at "Mar 4, 99 09:21:10 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Amancio Hasty said: > > Actually, given that most likely we have quite a few ex-VMS hackers I am > surprised > that you have to explain or sell the idea of an async gate maybe you ought > to refer to the term as a QIO 8) > I am quite familar with qio$ stuff. It is cool, but so is AIO, and AIO is the standard. qio$ is really neat, when on I/O completion, an AST is posted. AIO is really neat, when on I/O completion a (real-time|normal) signal is posted. What is missing is a nicely sized set of real-time signals. I seem to remember that NetBSD has expanded their signal set. It would behoove FreeBSD to increase the signal set to include 32,64,96 realtime signals. If handling the UNIX-type API, more work needs to be done, like realtime signals (with a nice number of them.) More things become interesting at that point. Rather than inventing a whole raft of something that is as complex as the goal, and then emulating the goal with that infrastructure -- it is sometimes just as easy to produce the goal directly. These new fangled computers encourage complex answers to simple problems, I suggest just solving the problem. Nowadays, I don't think that some of us could implement a debug monitor on a PDP-8, because it is obviously impossible :-). With 2-3 days of unscrambled thought, I could upgrade AIO to implement much more true async I/O than it does today, without threads. The only really problematical part would be the network code, but to solve the problem without threads (so it would be efficient), might require more internal hacking than I want to do. Note that the AIO code as it is, can queue multiple raw I/O requests to multiple devices in one system call. The completion can be signaled, tested for, or blocked on (in an or or and fashion.) There is little else than to increase the number of signals (for convienence), and improve the signal semantics to the real-time posix requirements. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903050538.AAA20475>