Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
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 >
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |