Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Asynchronous File I/O on Linux



On May 18, 2010, at 1:01 PM, Bill Bogstad wrote:
> 
> He also doesn't want to open the file multiple times which causes a
> problem since a file descriptor can only have one lseek() position at
> a time.   I can imagine scenarios (for example a library might be

This is why you create a bunch of threads, each with its own file handle, each file handle with its own unique pointer.  You have to open the file multiple times and run each read() in its own thread to truly parallelize the read operations.


> Err, CPU cycles are practically free compared to disk seeks.   That's
> why disk schedulers implement things like elevator algorithms rather
> then FIFO:

They're not free if your poll/select loop is waiting for input from the device.  In other words, you're blocking on the I/O anyway, you're just shifting where you block from the kernel into a loop in your program.

--Rich P.








BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org