new i/o library

[Duncan Coutts]

On Fri, 2006-01-27 at 13:10 +0300, Bulat Ziganshin wrote:

> moreover, i have an idea how to implement async i/o without complex
> burecreacy: use mmapped files, may be together with miltiple buffers.
> for example, we can allocate four 16kb buffers. when one buffer is
> filled with written data, the program unmaps it and switches to use
> the next buffer. i don't tested it, but OS can guess that unmapped
> buffer now should be asynchronously written to disk. the same for
> reading - when we completely read one buffer, we can unmap it, switch
> to the second buffer and map the third so that the OS can
> asynchronously fill the third buffer while we are reading second.
> should this work, at least on the main desktop OSes?

On Linux an probably other unix-like OSes I don't think this would be
any different from using read/write.

On Linux, read and mmap use the same underlying mechanism - the page
cache. The only difference is that with mmap you get zero-copy access to
the page cache. However frequent mapping and unmapping may eliminate
that advantage. Either way there is no difference in how asynchronous
the operations are.

For the write case write() is already asynchronous. The data is just
copied into the page cache and the OS flushes it some time later at a
time of its own choosing.

For the read case mmap()ing and then reading will still be synchronous
because the file is not mapped until the memory is accessed. At which
point the thread that accesses that memory will block to perform the IO.
You can use posix_madvise() hints to ask the OS to pre-fault the mmaped
pages however the actual implementation of this is still synchronous.
The best you can do is to use hints to get the OS to do plenty of read
ahead (if you are going to access the file sequentially). This will
populate the page cache and so hopefully the data will be immediately
available when you ask for it shortly afterwards. However, even this
will be of limited additional benefit since the OS can automatically
detect linear access patterns and increase the read ahead accordingly.

On a related note, if you know that a file will be accessed linearly and
then not re-read after that, then you can give a hint to not retain the
data in the page cache after it has been read by the process.

Duncan