Re: lockf and kernel threads

[ Available lists | Index of freebsd-hackers | Month of Mar 1999 | Week of 4 Mar 1999 | Raw email | View thread | Wrap long lines | Reply ]
From
Amancio Hasty <hasty@rah.star-gate.com>
Date
4 Mar 1999 21:46:44
Subject
Re: lockf and kernel threads
Message-ID
199903050545.VAA62143@rah.star-gate.com

In reply to

[ Hide this part ]
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



Elapsed time: 0.111 seconds