Сигналы. Зачем использовать флаг SA_RESTART?

Зачем использовать флаг SA_RESTART, если он поддерживается "некоторыми" системами для "некоторых" системных вызовов? Не надежней ли делать проверку на наличие EINTR?

0

Сообщение от neurosis Я имею ввиду, почему бы не забить на SA_RESTART, и сделать, например, функции-обертки для сис. вызовов... ну типа того

Если не сделаешь SA_RESTART, то после обработки сигнала программа помрёт. Вроде бы как. Ты лучше скажи, что ты в конечном итоге хочешь увидеть

0

Сообщение от Evg Если не сделаешь SA_RESTART, то после обработки сигнала программа помрёт.

Чо?

SA_RESTART Поведение должно соответствовать семантике сигналов BSD и позволять некоторым системным вызовам работать, в то время как идет обработка сигналов.

Источник: http://www.opennet.ru/man.shtm... %D4%D8+man

Ты лучше скажи, что ты в конечном итоге хочешь увидеть

Хочу быть уверенным в том, что если какой-нибудь сис. вызов (accept() например) прервется сигналом, то он будет перезапущен

0

Сообщение от neurosis Чо?

Я несколько криво выразился. У каждого сигнала есть дефолтное поведение, которое выражается либо в игнорировании сигнала, либо в прибитии процесса. Может есть ещё какое-то дефолтное поведение, но навскидку не вспомню

Сообщение от neurosis Хочу быть уверенным в том, что если какой-нибудь сис. вызов (accept() например) прервется сигналом, то он будет перезапущен

А о каком сигнале идёт речь? Если это внешний сигнал типа SIGINT, то программа умрёт, ибо это дефолтное поведение сигнала

А вообще, по таким сложным вещам крайне НЕ рекомендую читать русскоязычные переводы. Или по крайней мере перевод без оригинала под рукой. Не раз уже встречался с тем, что русский вариант невозможно понять, либо переведено формально правильно, но с возможной двоякой трактовкой и первая трактовка, которая приходит на ум, оказывается неверной

0

Сообщение от neurosis Хочу быть уверенным в том, что если какой-нибудь сис. вызов (accept() например) прервется сигналом, то он будет перезапущен

Вы же сами прекрасно понимаете, что SA_RESTART вам этой уверенности не даст т.к. accept() перезапускается далеко не везде и не всегда.
Т.е. его именно оборачиваем по типу как вы показали для read() с добавками по вкусу типа ловли EAGAIN, учета ожидающих соединений и тд.

Добавлено через 7 минут

Сообщение от Evg А о каком сигнале идёт речь? Если это внешний сигнал типа SIGINT, то программа умрёт, ибо это дефолтное поведение сигнала

Все чудеснее и чудеснее становиться, но после перла "Если не сделаешь SA_RESTART" не вставляет)
Сможете поведать что такое "внешний" сигнал, и очевидно "внутренний"? Ну или хотя бы разницу между ними.
И почему код должен помирать от SIGINT? это же не SIGKILL...

0

Сообщение от g_u_e_s_t Сможете поведать что такое "внешний" сигнал, и очевидно "внутренний"?

Любишь ты разводить клоунаду на ровном месте. Тебе, очевидно, куда больше нравится асбтрактно препираться и меряться, чем отвечать человеку на конкретный вопрос

"Внешний" сигнал - сигнал, вызванный "внешними" по отношению к задаче причинами: пользователь нажал Ctrl-C, пользователь набрал в консоли kill, другая программа (в том числе и родственная программа, или поток) послала сигнал. "Внутренние" сигналы возникают по причинам, вызыванным работой саой программы: программа сама себе послал сигнал, программа выполнила недопустимую операцию, программа нарвалась на плавающее исключение и т.п.

0

Мне казалось, что по сути я ответил в 1м посте и ТС ответ удовлетворил...
Могу повторить если нас читают "танкисты":
Я считаю, что смысл использовать SA_RESTART при написании нового портабельного кода (а не адаптации старого BSD4) есть _только_ в одном случае - не возможность проверить EINTR. Во всех остальных случаях его использовать _не_ надо т.к. учет поведение всего зоопарка современных ОС потребует неоправданно много труда на разработку и отладку.
Наиболее простая, а потому более надежная стратегия запрещать сигналы в критических местах кода.

Если вы с этим не согласны, то я с _удовольствием_ выслушаю аргументы.
А пока от вас слышно только "вопроса я не понял", словоблудие на тему "не читайте советских газет" и весьма вольный пересказ ман sigaction

"Внешний" сигнал - сигнал, вызванный "внешними" по отношению к задаче причинами: пользователь нажал Ctrl-C, пользователь набрал в консоли kill, другая программа (в том числе и родственная программа, или поток) послала сигнал. "Внутренние" сигналы возникают по причинам, вызыванным работой саой программы: программа сама себе послал сигнал, программа выполнила недопустимую операцию, программа нарвалась на плавающее исключение и т.п.

Вы забыли пояснить самое главное: какая разница _кто_ послал сигнал???
Как (непонятно зачем) введенное вами разделение сигналов на "внутренние" и "внешние" влияет на поведение SA_RESTART или на EINTR или на что-то еще?
Может программа не упадет если пошлет сама себе _любой_ не запрещенный сигнал для которого не установлен обработчик? так нет.
Может "внешние" сигналы надо обрабатывать как-то по особенному? так тоже нет.
В чем же разница???

0

Сообщение от g_u_e_s_t Могу повторить если нас читают "танкисты": Я считаю, что смысл использовать SA_RESTART при написании нового портабельного кода (а не адаптации старого BSD4) есть _только_ в одном случае - не возможность проверить EINTR. Во всех остальных случаях его использовать _не_ надо т.к. учет поведение всего зоопарка современных ОС потребует неоправданно много труда на разработку и отладку.

А не судьба было сразу вот так написать? По крайней мере хоть что-то внтяно написанное, которое можно прочитать и понять

Сообщение от g_u_e_s_t Вы забыли пояснить самое главное: какая разница _кто_ послал сигнал???

Я, например, не имею чёткого представления о том, что конкретно из себя представляет постановка задачи у топикстартера. С какими сигналами и при каких условиях возникающими борется автор. Поэтому предпочитаю обсуждение конкретной проблемы, а не абстрактной

0

Сообщение от Evg А не судьба было сразу вот так написать? По крайней мере хоть что-то внтяно написанное, которое можно прочитать и понять

Поймите, очевидно человек задающий подобный вопрос _априори_ знает и понимает о чем идет речь.
И рассусоливать ему разницу между BSD и SVR способами работы с сигналами _не_ нужно.
Наверное дело в том, что вы не читали Стивенса (его можно добыть и в оригинале, но поверьте на слово, перевод адекватный).

Я, например, не имею чёткого представления о том, что конкретно из себя представляет постановка задачи у топикстартера. С какими сигналами и при каких условиях возникающими борется автор. Поэтому предпочитаю обсуждение конкретной проблемы, а не абстрактной

Давайте по пунктам:
1. Какие сигналы:
это не важно, для _любого_ сигнала который можно перехватить поведение в контексте SA_RESTART будет одинаковым.
2. Условия возникновения:
И это не важно. Т.к. если сигнал явным образом не блокирован программой поведение системы _не_ измениться в независимости от того кто и как этот сигнал не послал.
3. Собственно сискол который может быть прерван:
Да тут есть, о чем говорить. Как уже минимум 3раза писалось в этом топике тут полные разброд и шатания у разных ОС. А учитывая качество man'ов отстающих от реальности на годы, дело вообще плохо. Именно это и есть основной довод против применения SA_RESTART.
В качестве прикола в свое время в comp.unix.programmer утверждали, что ранний линукс мог вернуть EINTR на sigaction()

0

Сообщение от g_u_e_s_t 1. Какие сигналы: это не важно, для _любого_ сигнала который можно перехватить поведение в контексте SA_RESTART будет одинаковым.

Одинаковым по сравнению с чем?

Сообщение от g_u_e_s_t 2. Условия возникновения: И это не важно. Т.к. если сигнал явным образом не блокирован программой поведение системы _не_ измениться в независимости от того кто и как этот сигнал не послал.

Можно поставить обработчик SIGINT (грубо говоря, реакция на Ctrl-C). Можно настроить обработчик таким образом, что он понимает, что программа в данный момент выполняет критическую операцию и прерываться нельзя (но если ничего критического нет, то можно и прерваться). Такой обработчик должен быть настроен через SA_RESTART. А если при получении Ctrl-C мы всегда будем завершаться, но при этом обработчик согнала нам нужен для каких-то посмертных действий, то настраиваем обработчик без SA_RESTART

0

Сообщение от Evg Одинаковым по сравнению с чем?

Как следует из названия пункта №1 с __любым__ другим перехватываемым сигналом.

Сообщение от Evg Можно поставить обработчик SIGINT (грубо говоря, реакция на Ctrl-C). Можно настроить обработчик таким образом, что он понимает, что программа в данный момент выполняет критическую операцию и прерываться нельзя (но если ничего критического нет, то можно и прерваться). Такой обработчик должен быть настроен через SA_RESTART.

Простите, но последнее предложение мягко говоря весьма спорно.
Фактически этим вы утверждаете, что такого же поведения не добиться проверкой на EINTR.
Что очевидно является не правдой.

0

Сообщение от g_u_e_s_t Как следует из названия пункта №1 с __любым__ другим перехватываемым сигналом

Сравниваем-то мы вариант с SA_RESTART и без него. А не два разных сигнала с SA_RESTART

Сообщение от g_u_e_s_t Фактически этим вы утверждаете, что такого же поведения не добиться проверкой на EINTR

Я ничего не утверждаю. Я просто привёл пример одной из жизненных ситуаций.

А вот обрабатывать EINTR - это уже вопрос второго уровня: если у нас нет сигналов с SA_RESTART, то EINTR вроде бы как и незачем обрабатвывать (потому что таких ситуаций быть не должно). Если имеются обработчики с SA_RESTART, значит в программе мы должны учесть такую возможность. Если мы знаем, что по SIGINT'у мы отложим завершение работы только в том случае, если формируется файл сданными, то нам, мягко говоря, плевать на EINTR'ы, возникшие в accept'ах. Если мы будем откладывать завершение до того момента, пока не прочтём все данные из сети, то приработе с read нам надо заложить возможность возникновения EINTR'а. Потому я и говорю, что хотелось бы обсудить конкретную причину в конкретной задаче

0

Сообщение от Evg Сравниваем-то мы вариант с SA_RESTART и без него. А не два разных сигнала с SA_RESTART

К чему тогда все ваше юление на тему "а какой конкретно сигнал ловит ТС???

Я ничего не утверждаю. Я просто привёл пример одной из жизненных ситуаций.

Так не пишите должен, пишите может. И объясняйте чем это лучше проверки EINTR. Иначе это переливание из пустого в порожнее.

Сообщение от Evg А вот обрабатывать EINTR - это уже вопрос второго уровня: если у нас нет сигналов с SA_RESTART, то EINTR вроде бы как и незачем обрабатвывать (потому что таких ситуаций быть не должно).

Простите, но это уже откровенный бред. Все с точность до наоборот. Как раз с SA_RESTART на некоторых сисколах вы EINTR и не увидите. И по этому если у нас нет сигналов с SA_RESTART то обрабатывать EINTR как раз надо. Впрочем и с SA_RESTART тоже надо тк опять же не все сисколы могут быть перезапущенны.

0

Сообщение от g_u_e_s_t К чему тогда все ваше юление на тему "а какой конкретно сигнал ловит ТС???

Ты можешь с людьми нормально общаться или принципиально себя ведёшь по-хамски? Между мной и тобой разница в том, что я разговариваю, а ты споришь. А потому свои замашки типа "юление" оставь для своей жены (когда она у тебя появится). Я всего лишь пытаюсь понять, что конкртено хочет автор

Сообщение от g_u_e_s_t Как раз с SA_RESTART на некоторых сисколах вы EINTR и не увидите

А на некоторых увижу? Или что? Опять-таки хочу тебе напомнить. Я не спорю, я спрашиваю

Сообщение от g_u_e_s_t И по этому если у нас нет сигналов с SA_RESTART то обрабатывать EINTR как раз надо

Действительно, я напутал

0

Сообщение от Evg Ты можешь с людьми нормально общаться или принципиально себя ведёшь по-хамски? Между мной и тобой разница в том, что я разговариваю, а ты споришь. А потому свои замашки типа "юление" оставь для своей жены (когда она у тебя появится). Я всего лишь пытаюсь понять, что конкртено хочет автор

Извините, я не хотел вас обидеть (и например не тыкаю вам в отличии от). Если бы вы производили впечатление студента я бы, изначально писал вам иначе, разжевывая и поясняя каждый шаг. Я же предположил (возможно ошибочно) что вы в курсе вопроса... Так что оставьте в покое мою семью и давайте начнем с начала.

Сообщение от Evg А на некоторых увижу? Или что? Опять-таки хочу тебе напомнить. Я не спорю, я спрашиваю

Да. некоторые сисколы система при установленном SA_RESTART перезапустит и соответственно EINTR вы не увидите, другие же перезапустить не возможно (например connect) и соответственно вернет EINTR. Списки перезапускаемых сисколов можно глянуть в районе man 7 signal, man 2 signal, man sigaction или рядом в зависимости от системы.
Попробую резюмировать специально для вас.
1. Любой доставленный сигнал без флага SA_RESTART прервет любой сискол (ну или покрайней мере тот у которого в мане прописан EINTR)
2. Есле же для сигнала был установлен флаг SA_RESTART то тут начинаются неоднозначности.
Часть сисколов не будут перезапущенны и система вернет EINTR как для случая 1 (для портабельного приложения критично то, что конкретный список таких сисколов различен для разных систем.) Т.е. получается, что при использовании SA_RESTART мы все равно должны проверять EINTR.
Отсюда и вопрос ТС "а нафига тогда вообще использовать SA_RESTART". Ответ на него вы вроди видели.

1

Остался только один вопрос. Ты говоришь "перезапущен", но фактически это означает "доисполнить до конца начиная с точки прерывания" (другими словами, будет исполно так, как будто бы сигнала и не было)? Или всё-таки что-то другое (с ходу, например, не понятно, почему с connect'ом должны быть проблемы)?

0

Сообщение от Evg Остался только один вопрос. Ты говоришь "перезапущен", но фактически это означает "доисполнить до конца начиная с точки прерывания" (другими словами, будет исполно так, как будто бы сигнала и не было)? Или всё-таки что-то другое (с ходу, например, не понятно, почему с connect'ом должны быть проблемы)?

Тут как раз именно та ситуация, когда говорить абстрактно (не о конкретном сисколе) тяжело.
Например тот же read()/write() если успел хоть что-то прочитать/записать перезапускаться не будет, а вернет то что успел сделать на момент получения сигнала.
Конретно про connect там устроенно так (линукс):
Т.е. даже если коннект был блокируемый, система все равно поставит его в бэкграунд, и вернет EINTR
Для нас, прикладных программистов, это значит что если мы словили EINTR на сonnect() то придется делать poll/select на сокет. т.е. работать с ним как с не блокируемым.
Почему такие пляски? Подозреваю, что из-за TCP handshake, но утверждать не буду.

0