Kurenya писал(а):
вы путаете гарантированную доставку информации пользователю и возможность её восстановления .
если чтение /dev прошло с ошибкой , то какое-то последующее чтение пройдёт нормально с высокой вероятностью и ни системе , ни компу плохо от этого не будет .
а вот если потеряется информация с какого-нибудь датчика , то будут неприятности .
Или вы решили, что если после
ошибки чтения из /dev начнёте повторно долбить раз за разом такое же чтение, то вы из него, в конечном итоге, из него выдолбите сокровенные данные?
Ерунда! Ошибку чтения только вы сами можете сообщить из кода, и возникает она, как правило, из-за некорректности вашего же собственного обрабатывающего кода. С какой же стати 2-е, 5-е, или 155-е повторение той же ошибочной ситуаций в том же окружении "продолбит" в конце-концов ситуацию?
И, тем более, обратите ещё внимание на то, что в
многозадачной среде ваше пользовательское приложение, выполняющее циклический опрос типа:
Код: Выделить всё
while( 1 ) {
...
fread(str,len,1,dfd);
fseek(dfd,0,SEEK_SET);
usleep(100000);
...
};
-
никогда не будет гарантировано считывать ваши данные строго через 1 миллисекунду (за счёт вытеснения), каждая из этих 3-х операций -
блокирующая, на которой вы можете иметь задержки
сколь угодно больше предполагаемых (и это совершенно корректно и совпадает с требованиями real-time как они формулируются POSIX 1003b). Так что в этом случае у вас могут быть любые пропуски и потери данных.
А если у вас такая critical missian задача, что пропуск 1-го миллисекундного отсчёта сразу вызовет Армагедон, то вам ОС Linux
принципиально не годится.
Тогда
покупайте строго realtime OS QNX, с другой и строго детерминированной дисциплиной планирования, и реализовывайте всё это там.