Is it worth to keep file descriptors open in case i need to read the file 0…5 times per second?

Question

I develop cross-platform audio editor in C++ that reads media files at 0...5 times per second (in playing mode or when re-draw sound on screen). The implementation opens a file and keeps the descriptor opened between all the reading operations with that file.

I think it would be more friendly to user to not forbid any file operations even if that file is opened. I would allow user to delete that file EVEN while it is playing (if he/she wants). The program would just stop playing after next failed try to read next block from that file.

Is open()/close() operations are expensive on modern Windows / Linux / Mac OS systems?

But it would be hard to open()/close() huge MP3 files, because MP3's "seek()" may be expensive (reading headers of all the blocks before needed block).

Answer 1

Many pro audio apps (or at least some) keep files open durring playback and closed when not playing back -- it is fast enough to open and seek when redrawing needs to happen. However, Pro audio apps don't work natively with formats like MP3 -- they always convert to uncompressed formats first. One of the reasons for this is that the sample-accurate seek-time of MP3's is MUCH worse. In theory, an MP3 reading library could close the file and reopen where it left off if nothing changed, but I don't think MP3 libraries support this. By contrast, uncompressed files are super fast and easy to seek around.

Back to your question: Do you want to reopen and reseek for every screen redraw, and frequently durring playback? Well, you can, and it might not even be a drag on screen redraw compared with leaving it open. A modern machine can surely keep up durring playback with enough buffering, especially if it's just one file, so that's doable as well. If you really want to do it, you should do some tests to see what the performance hit is and see if you really want to slow the user's machine down just for this.

You also ask what's more "friendly"? You suggest the user might "change" the file in another app, but how and why? What happens, for instance, if your program tries to reopen at the moment when the user has "changed" it? The change might involve replacing it with another file, but many applications "replace" a file by first deleting the original, then writing the replacement (or moving the replacement into place). So what happens if your app tries to open the file at the wrong moment? It'll say, "oh file's gone, I'll stop playing now." Worse yet, the program opens when the replacement is only partially written. Yuck. I can imagine even worse, but that's a start.

If you need to write to the file (eg for ID3 tags) this can usually be done by opening the file in RW mode (or reopening an already open file descriptor), since it usually involves overwriting data or modifying data at the end of the file. I don't recommend doing any operation that changes the number of playback samples, the location of the playback samples, etc, durring playback unless you plan very carefully because the situation is full of race conditions. If you do do it, you should do it in your own app because those races are easier to control.

So maybe it's worth it, but I would strongly advise against it. If the other app is poorly written, bad things could happen.