Asynchronous File I/O on Linux

[nmeyers-BigylZdZcsdmcu3hnIyYJQ at public.gmane.org (Nathan Meyers)]

On 05/16/2010 12:24 PM, Jerry Feldman wrote:
> On 05/16/2010 11:56 AM, Richard Pieri wrote:
>    
>> On May 16, 2010, at 10:06 AM, Mark Woodward wrote:
>>
>>      
>>> Well, it is "async" in the view that I want to issue multiple read
>>> requests simultaneously from the same execution context (thread or
>>> process). What I want to test is *if* I can issue multiple read requests
>>>
>>>        
>> That's definitely not asynchronous I/O.  Asynchronous means that the calling process doesn't wait for the write call to finish.  That is, the process runs asynchronously to the write.  Reads are always synchronous.
>>
>> What you described is either concurrent or parallel (I'm not precisely sure which term is most appropriate) reads.  Can you do it?  Sure, just as I described: create as many file handles to the file that you need with open().  Each file handle has its own unique read/write pointer to the file.
>>
>>      
> Additionally, Linux (and Unix) always buffer file I/O. When a file is
> open, there will be several buffers containing data for a file.
> Essentially, if you are reading (assume a random piece of data), if that
> block happens to be in memory already you will retrieve it from the
> buffers, otherwise it will cause a physical read. Additionally, when you
> write, you are not guaranteed that your data will be immediately written
> to disk. Certainly, you can control whether a file is buffered or not,
> but I would avoid using unbuffered files, and I would avoid flushing the
> data to disk if you want performance.
>    

If you know enough about your access patterns that you can do a better 
job of buffering than what standard libc logic does, you can choose to 
use the unbuffered I/O calls (read(2) and write(2)) instead of the 
buffered calls (fread(3), fwrite(3), and all the other stdio stuff). But 
you can destroy performance if you try this without really knowing what 
you're doing.

Nathan



>    
>
>
> _______________________________________________
> Discuss mailing list
> Discuss-mNDKBlG2WHs at public.gmane.org
> http://lists.blu.org/mailman/listinfo/discuss
>