Стоит ли держать файловые дескрипторы открытыми на случай, если мне нужно будет прочитать файл 0 … 5 раз в секунду?
Я разрабатываю кроссплатформенный аудиоредактор на C ++, который читает медиафайлы со скоростью 0 … 5 раз в секунду (в режиме воспроизведения или при перерисовке звука на экране). Реализация открывает файл и сохраняет дескриптор открытым между всеми операциями чтения с этим файлом.
Я думаю, что было бы более удобно для пользователя не запрещать файловые операции, даже если этот файл открыт. Я бы позволил пользователю удалить этот файл даже во время его воспроизведения (если он / она хочет). Программа просто остановит воспроизведение после следующей неудачной попытки прочитать следующий блок из этого файла.
Являются ли операции open () / close () дорогими в современных системах Windows / Linux / Mac OS?
Но было бы трудно открыть () / close () огромные MP3-файлы, потому что MP3 «seek ()» может быть дорогим (чтение заголовков всех блоков перед необходимым блоком).
Решение
Многие профессиональные аудио-приложения (или, по крайней мере, некоторые) сохраняют файлы открытыми во время воспроизведения и закрываются, когда не воспроизводятся — это достаточно быстро, чтобы открывать и искать, когда требуется перерисовка. Однако приложения Pro audio не работают с такими форматами, как MP3, — они всегда сначала конвертируются в несжатые форматы. Один Причин для этого является то, что время поиска MP3 с точностью до сэмпла НАМНОГО хуже. Теоретически, библиотека чтения MP3 может закрыть файл и открыть его там, где он остановился, если ничего не изменилось, но я не думаю, что библиотеки MP3 поддерживают это. Напротив, несжатые файлы очень быстрые и их легко найти.
Возвращаясь к вашему вопросу: хотите ли вы заново открывать и перезаписывать каждый экран перерисовки и часто во время воспроизведения? Ну, вы можете, и это может быть даже не перетаскивание на экране перерисовки по сравнению с оставлением его открытым. Современная машина наверняка может поддерживать непрерывное воспроизведение с достаточной буферизацией, особенно если это всего лишь один файл, так что это также выполнимо. Если вы действительно хотите это сделать, вам следует провести несколько тестов, чтобы увидеть, как снижается производительность, и посмотреть, действительно ли вы хотите замедлить работу компьютера пользователя только для этого.
Вы также спрашиваете, что является более «дружелюбным»? Вы предлагаете пользователю «изменить» файл в другом приложении, но как и почему? Что произойдет, например, если ваша программа попытается открыть ее в тот момент, когда пользователь ее «изменил»? Изменение может включать замену его другим файлом, но многие приложения «заменяют» файл, сначала удаляя оригинал, затем записывая замену (или перемещая замену на место). Так что же произойдет, если ваше приложение попытается открыть файл не в тот момент? Он скажет: «О, файл исчез, я перестану играть сейчас». Что еще хуже, программа открывается, когда замена написана только частично. Тьфу. Я могу представить себе еще хуже, но это только начало.
Если вам необходимо выполнить запись в файл (например, для тегов ID3), это обычно можно сделать, открыв файл в режиме RW (или повторно открыв дескриптор уже открытого файла), так как обычно он включает перезапись данных или изменение данных в конце файл. Я не рекомендую выполнять какие-либо операции, которые изменяют количество сэмплов воспроизведения, расположение сэмплов воспроизведения и т. Д. Во время воспроизведения, если вы не планируете очень тщательно, потому что ситуация полна условий гонки. Если вы делаете это, вы должны делать это в своем собственном приложении, потому что эти гонки легче контролировать.
Так что, возможно, оно того стоит, но я бы настоятельно рекомендовал против этого. Если другое приложение плохо написано, могут произойти плохие вещи.
Другие решения
Других решений пока нет …