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 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 | |
We also thank MIT for the use of their facilities. |