Хотел тут в одном месте заменить fopen/fwrite на creat/write
Посмотрел man по write
Там есть среди возвращаемых ошибок EINTR, типа "попробуйте ещё раз".
Возникло ощущение, что я чего-то не понимаю. Если на эту ошибку всегда надо реагировать одинаковым способом, то почему она не обрабатывается самой функцией? Если же ошибку можно обрабатывать разными способами, то какие ещё есть альтернативы и для чего?
Поискал в гугле и на rsdn, обстоятельного объяснения этому не нашёл. Пишется "так надо потому что надо".
А fwrite уже обрабатывает эту ошибку как надо? Или программа написанная по стандарту C может оказаться неработоспособной в UNIX?
Правильно работающая программа — просто частный случай Undefined Behavior
Здравствуйте, _Winnie, Вы писали:
_W>Хотел тут в одном месте заменить fopen/fwrite на creat/write _W>Посмотрел man по write _W>Там есть среди возвращаемых ошибок EINTR, типа "попробуйте ещё раз".
man 2 write
EINTR The call was interrupted by a signal before any data was written.
If a write() is interrupted by a signal handler before any bytes are written, then the call fails with the error EINTR.
Что-то не вижу, тут "типа попробуй еще раз". Может после прихода опр. сигнала, смысл что-то куда-то писать, пропадает?
_W>Там есть среди возвращаемых ошибок EINTR, типа "попробуйте ещё раз". _W>Возникло ощущение, что я чего-то не понимаю. Если на эту ошибку всегда надо реагировать одинаковым способом, то почему она не обрабатывается самой функцией?
Потому что не всегда нужно реагировать одинаковым образом. Например если пришел SIGTERM логичнее будет завершить программу, а не повторять сисколл.
Здравствуйте, _Winnie, Вы писали:
_W>Хотел тут в одном месте заменить fopen/fwrite на creat/write _W>Посмотрел man по write _W>Там есть среди возвращаемых ошибок EINTR, типа "попробуйте ещё раз". _W>Возникло ощущение, что я чего-то не понимаю. Если на эту ошибку всегда надо реагировать одинаковым способом, то почему она не обрабатывается самой функцией?
Потому что есть случаи, когда прерывание сигналом означает, что просто пришёл асинхронный сигнал, его обработали и надо продолжить чтение/запись дальше, а есть случаи, когда прерывание сигналом означает, что читать/писать дальше нет смысла.
Это регулируется на уровне собственно сигналов — в настройке обработчика задаётся через флаг SA_RESTART, начинать ли заново после сигнала, и по крайней мере на read и write это действует.
_W> Если же ошибку можно обрабатывать разными способами, то какие ещё есть альтернативы и для чего?
См. выше.
_W>Поискал в гугле и на rsdn, обстоятельного объяснения этому не нашёл. Пишется "так надо потому что надо". _W>А fwrite уже обрабатывает эту ошибку как надо? Или программа написанная по стандарту C может оказаться неработоспособной в UNIX?
Не надо громких слов типа "по стандарту C". Unix API — это не против C, точно так же как stdio само по себе взятое — это ещё не C. Пожалуйста, называйте вещи своими именами — это поможет Вам же в будущем.
Сочетание stdio и обработкой сигналов возможно и не имеет принципиальных проблем. Если запись вообще не состоялась, fwrite вернёт 0 и EINTR в errno. Но проблема может быть в том случае, если записывалось, например, 4 порции по 2000 байт, а записалось 3.14 (укороченный кусок посредине одной порции), в таком случае я не ручаюсь за все реализации, что они правильно это отработают.