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 11:56 AM, Richard Pieri wrote: > On May 16, 2010, at 10:06 AM, Mark Woodward wrote: > =20 >> Well, it is "async" in the view that I want to issue multiple read=20 >> requests simultaneously from the same execution context (thread or=20 >> process). What I want to test is *if* I can issue multiple read reques= ts=20 >> =20 > That's definitely not asynchronous I/O. Asynchronous means that the ca= lling process doesn't wait for the write call to finish. That is, the pr= ocess 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 a= s 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 f= ile. > =20 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. --=20 Jerry Feldman <gaf-mNDKBlG2WHs at public.gmane.org> Boston Linux and Unix PGP key id: 537C5846 PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C 5846
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |