Если я буду стирать после каждой записи, не происходит ли частичная запись? [Дубликат]
Мне нравится идея объектов модели и Mock-объектов на основе NSProxy для фиксации или удаления данных, если пользовательский выбор может быть отменен.
Легко передавать данные, поскольку это один объект или пара объектов, и если вы скажете UINavigationController-контроллер, вы можете сохранить ссылку на модель внутри, и все нажатые контроллеры представлений могут получить к ней доступ непосредственно от контроллера навигации .
1 ответ
Без канала связи нет гарантированного метода предотвращения чтения с нулевым байтом или даже длительных периодов зависания без чтения каких-либо данных при чтении файла, который активно записывается. Реализация Linux tail использует inotify для эффективного создания канала связи и получения информации о активности записи файла.
Это довольно интересная проблема для того, чтобы IBM даже опубликовала Redbook , описывающий реализацию, которая смогла выполнить такую «чтение-запись-запись» со скоростью около 15 ГБ / с:
Read-behind-write - это метод, используемый некоторыми высококлассными клиентам снизить латентность и повысить производительность. Техника чтения-записи-записи означает, что, как только писатель начнет писать, читатель сразу зайдет позади, чтобы прочитать; идея состоит в том, чтобы наложить время записи на время чтения. Эта концепция полезна для машин с медленной производительностью ввода-вывода. Для высокопроизводительной машины ввода-вывода, такой как pSeries 690, может быть стоит рассмотреть возможность первой записи всего файла в параллель, а затем повторного считывания данных.
Существует много способов считывания данных -write можно реализовать. В схеме, реализованной Xdd, после того, как писатель пишет одну запись, она будет ждать, пока читатель прочитает эту запись до того, как писатель сможет продолжить. Несмотря на то, что эта схема позволяет синхронизировать запись и считыватель только с одной записью, требуется системное время для блокировки и синхронизации между писателем и читателем.
Если вам неинтересно, сколько записей читает читатель за писателем, тогда можно реализовать схему для писателя, чтобы потопить записи как можно быстрее. Писатель может обновить глобальную переменную после записи определенного количества записей. Читатель может затем вытащить глобальную переменную, чтобы узнать, сколько записей она должна читать.
Без канала связи вам остается много продолжать, возможно, вызывая
sleep()или что-то подобное после нескольких результатов с нулевым байтомread().