Asynchronous File I/O on Linux

Richard Pieri richard.pieri-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org
Tue May 18 13:19:28 EDT 2010


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.







More information about the Discuss mailing list