Date: Thu, 04 Mar 1999 21:45:12 -0800 From: Amancio Hasty <hasty@rah.star-gate.com> To: dyson@iquest.net Cc: tlambert@primenet.com, dick@tar.com, jplevyak@inktomi.com, hackers@FreeBSD.ORG Subject: Re: lockf and kernel threads Message-ID: <199903050545.VAA62143@rah.star-gate.com> In-Reply-To: Your message of "Fri, 05 Mar 1999 00:38:46 EST." <199903050538.AAA20475@y.dyson.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903050545.VAA62143>