lkml.org 
[lkml]   [1998]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:42    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site