Messages in this thread | | | Date | Thu, 02 Apr 1998 01:19:40 -0800 | From | Robey Pointer <> | Subject | Re: I/O completion ports for Linux |
| |
Alan Cox wrote: > > > Normal unix asynchronous I/O uses signals to notify a process/thread > > that some I/O operation won't block, but no information is given to > > the process beyond that signal. Solaris' aio_read/write (when they > > are implemented) will queue the request but will still use signals > > to notify the process of completion. Linux IOCP avoids signals > > altogether. > > If you look at the current kernels and the real time signals you should > always be able to return a value with a real time signal and also be able > to pass one item of data back (like the file descriptor) > > Personally I'd rather see posix AIO come oout of such work, directly or > indirectly.
[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
| |