[lkml]   [1998]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: I/O completion ports for Linux
Theodore Y. Ts'o wrote:
> This is not to say that completion ports are not without their problems.
> There are also questions of what happens if you try to register more
> than one asyncronous I/O --- does it return an error, overwrite the
> previous I/O request, etc? Do you allow asyncronous reads and writes?
> Since I'm on the road, I still haven't had a chance to look at Robey's
> proposal, but there are some design/API questions that we need to
> consider.

My current implementation keeps a queue of operations per
completion-port. So it's possible to have multiple outstanding I/O
requests on one fd -- but they're served in the order that you made the
requests. I believe NT only allows one oustanding async I/O request per
fd, which strongly indicates that they store this info in their
equivalent of "struct file". I'm not sure how much of a limitation this
is in practice... ? It would simplify the implementation a lot, but I'm
not sure if it's a good thing overall. It seems like there are probably
some pretty good reasons that you might want to have two or more
outstanding async I/O requests on a single fd.

Robey Pointer | "So that's what an invisible barrier | looks like." -Time Bandits | (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

 \ /
  Last update: 2005-03-22 13:42    [W:0.047 / U:3.632 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site