From owner-freebsd-hackers Thu Mar 4 21:46:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rah.star-gate.com (rah.star-gate.com [209.249.129.138]) by hub.freebsd.org (Postfix) with ESMTP id 38C7D14FEC for ; Thu, 4 Mar 1999 21:46:42 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.1/8.8.8) with ESMTP id VAA62143; Thu, 4 Mar 1999 21:45:12 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199903050545.VAA62143@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: dyson@iquest.net Cc: tlambert@primenet.com, dick@tar.com, jplevyak@inktomi.com, hackers@FreeBSD.ORG Subject: Re: lockf and kernel threads In-reply-to: Your message of "Fri, 05 Mar 1999 00:38:46 EST." <199903050538.AAA20475@y.dyson.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Mar 1999 21:45:12 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Whats your love with signals ? With respect to AIO , standards are great when their work... Amancio > 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