From owner-freebsd-hackers Thu Mar 4 21:39: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (Postfix) with SMTP id 3B2CF14F0F for ; Thu, 4 Mar 1999 21:39:06 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 16806 invoked from network); 5 Mar 1999 05:38:45 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 5 Mar 1999 05:38:45 -0000 Received: (from toor@localhost) by y.dyson.net (8.9.1/8.9.1) id AAA20475; Fri, 5 Mar 1999 00:38:46 -0500 (EST) Message-Id: <199903050538.AAA20475@y.dyson.net> Subject: Re: lockf and kernel threads In-Reply-To: <199903050521.VAA56233@rah.star-gate.com> from Amancio Hasty at "Mar 4, 99 09:21:10 pm" To: hasty@rah.star-gate.com (Amancio Hasty) Date: Fri, 5 Mar 1999 00:38:46 -0500 (EST) Cc: tlambert@primenet.com, dyson@iquest.net, dick@tar.com, jplevyak@inktomi.com, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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