[Oddly, almost a week after posting, I still haven't seen my original
message appear on the mailing list. I never realized there was that
much lag... :) ]
Well, I have to admit that I cheated a bit on the "async" part. The
current patch just does the read/write in the context of one of the
tasks that's blocking on the completion-port read. Without anyone
blocking on an IOCP read, the queued reads and writes won't happen.
(The bh just wakes up one of the tasks sleeping on the IOCP, and that
task ends up doing the actual read or write when it's scheduled next.)
To be able to emulate posix AIO, that restriction won't work. And
actually I don't like the restriction for IOCP either, it's just a
stopgap until I can figure out the "right" way.
In my head, I've been tossing around the idea of having a kernel thread
(just one) devoted to all async I/O. All open IOCP's could be chained
together, and the kernel "async I/O" thread could be woken up whenever
one of the pending I/O operations is likely to succeed. I know kernel
threads are to be avoided, but hey, it's just one... for the entire
async I/O system... :)
The problem as I see it is that only the BH handlers will know when the
time is ripe for a read or write to succeed -- but obviously the actual
read or write can't happen from there, so the BH is limited to just
"waking up" some task, and letting that task do the actual I/O. If it's
not some blocked user task, it needs to be a kernel thread.
Anyone with ideas, please email me, since I don't have anyone that I can
talk to in person who knows what the !@#$ I'm talking about. :) I'm
just hacking away in the dark here...
Robey
-- Robey Pointer | "So that's what an invisible barrier robey@lag.net | looks like." -Time Bandits http://www.lag.net/~robey | (join the 90's retro bandwagon early!)- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu