>well, the deal with async io is that it allows a process to keep
>running while it's waiting for io. typically, the process will get some
>signal to tell it that it can pick up the data when it's ready. (this, i
>guess, is why you can't have multiple outstanding requests, since each one
>would need a different signal). the problem withdoing this in unix is it's
>against the basic model where a process goes into kernel mode when it's doing
>io (and other stuff), and is stuck there until the kernel is done with
>whatever its doing.
>one solution in linux is to just launch off another thread to do the io
>which'll get stuck in kernel mode, not the whole process. but this is kind of
>cheesy, and has the overhead of creating a new thread.
Also it just doesn't fit the design of some programs. For example the design
of the Squid web cache is based around a single thread which does everything
with a finite state machine. Asynchronous IO fits in well with this design, IO
threads don't.
>> From what I've heard NT allows numerous (unlimited?) outstanding
>> async-IO requests to be queued to the system, and programmers love
>> this. Can someone validate this? It's what I've heard, I want to
>> know if it is true.
>>
>i dunno. i wonder how the kernel informs the threads that the io is done.
>perhaps there is a more flexible system in NT for signalling than in linux...
Under NT you can use "overlapped IO" structures to perform system calls to
discover the status of "overlapped IO" (the NT name for asynchronous IO). You
can query the system on the status of such calls on a per file handle (if there
is only one request per file handle) or per IO request.
Someone previously said that the existance of a single signal is the reason
for only allowing a single async-IO request. I don't think that this is a
problem, the API call to start an async-IO request could give the kernel an
address of a buffer to fill with appropriate completion results when the IO
request is complete. Then the finction which is called on the signal could go
through a list of such buffers and find which one finished.
Russell Coker