Перехват Сигнала

Тема работы "Сигналы". Мне дали доп задание: "Один источник посылает сигнал(любой, любым способом). Есть приёмник, который должен принимать эти сигналы. Нужно добавить перехватчик сигналов, и вывести количество перехваченных сигналов, если это получится". Кода нет вообще. Киньте хоть ссылки, где прочитать про эти перехватчики можно, ато я что-то совсем ничего не могу найти.

0

Сообщение от niXman имел ввиду саму обработку, а не доставку сигнала.

Поясни. Что значит асинхронная обработка

Сообщение от g_u_e_s_t Обработчика сигнала вестимо

Обработчик сигнала должен быть минимальный. И не вызывать функций, которые имеют побочные эффекты в виде записи в глобальную память, когда имеется шанс, что сигнал появится в процессе работы именно такой функции. Мне кажется, что об этом в любом учебнике написано

0

Сообщение от niXman имел ввиду саму обработку, а не доставку сигнала.

Посмотрел. Если не брать во внимание вариант с kqueue() (у которого есть свои минусы) это тонкая обертка над уже упомянутыми в этом топике примитивами.
Т.е. если у вас cpp проект уже использующий Boost:asio это будет очень удобный вариант, но тащить asio только ради сигналов - уж увольте...

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

Обработчик сигнала должен быть минимальный. И не вызывать функций, которые имеют побочные эффекты в виде записи в глобальную память, когда имеется шанс, что сигнал появится в процессе работы именно такой функции. Мне кажется, что об этом в любом учебнике написано

Я вам уже показывал, что в классике жанра, у Стивенса показан код c longjmp() - если вы думаете, что в других учебниках лучше, то это к сожалению не так.

0

Сообщение от Evg Поясни

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

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

Сообщение от g_u_e_s_t Если не брать во внимание вариант с kqueue()

это который?

Сообщение от g_u_e_s_t сли у вас cpp проект уже использующий Boost:asio это будет очень удобный вариант, но тащить asio только ради сигналов - уж увольте...

кому как...
у меня boost устанавливается первым после компилятора.

0

Сообщение от niXman Добавлено через 1 минуту это который?

На *BSD то о чем вы говорите сделано через kqueue(), соответственно man kqueue/kevent про EVFILT_SIGNAL

0

Сообщение от g_u_e_s_t то о чем вы говорите сделано через kqueue()

понял.

0

Сообщение от g_u_e_s_t Я вам уже показывал, что в классике жанра, у Стивенса показан код c longjmp()

А книга какого года? Потому что setjmp-longjmp "сейчас" и "раньше" работают (или могут работать) немного по разному. Сейчас, например, на linux'е есть два раздельных вызова: setjmp и sigsetjmp (с сохранением сигнальной маски и без неё). Т.е. код, нормально работающий на одной системе, может оказаться нерабочим на другой.

Я не считаю себя специалистом в данной области, а потому писать статью про тонкие моменты этого дела не буду.

Добавлено через 34 секунды

Сообщение от niXman ну вот поймали мы сигнал. в теле handler() мы можем сначала обработать сигнал а потом запустить снова ожидание. или, сначала запустить ожидание нового сигнала, а потом обработать текущий

А что значит "запустить ожидание"?

0

Сообщение от Evg А что значит "запустить ожидание"?

запустить ожидание следующего сигнала. оно ведь у нас асинхронное.
т.е. на один вызов async_wait() мы получим один сигнал. чтоб получить следующий, нужно снова вызвать async_wait()

0

Сообщение от niXman т.е. на один вызов async_wait() мы получим один сигнал. чтоб получить следующий, нужно снова вызвать async_wait()

Всё, понял, что подразумевалось под "асинхронной обработкой сигналов". Не знаю, насколько это хороший способ работы с сигналами в принципе. Т.е. у тебя программа начала что-то в цикле считать, но из-за косякой ушла в бесконечный цикл, после чего уже никакой сигнал обработан не будет

0

Сообщение от Evg программа начала что-то в цикле считать, но из-за косякой ушла в бесконечный цикл

о каком цикле речь?

0

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

У меня переиздание 2002г.
Это не linux это вполне себе честный POSIX.
Засада в том, что после longjmp() не будут восстановлены как минимум статические переменные в [g] libc и malloc-структуры, в не зависимости от того делали ли мы setjmp() или sigsetjmp()

Я не считаю себя специалистом в данной области, а потому писать статью про тонкие моменты этого дела не буду.

То же самое могу сказать и про себя, по этому и предложил чужой текст в качестве основы.
PS: вот тока сам текст вставить забыл)))
не лезет( форум говорит многа букф(((

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

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

Похоже таки не поняли)
Плюс и он же минус обертки в boost в том, что собственно к обработке сигнала пользовательский код _не_ пускают. Работает оно так: в реальном обработчике сигнал ставиться в очередь (почти как в ОС, но с гарантией, что сигнал не будет потерян), а собственно обработка уже происходит по вызову async_wait().
Т.е. правильнее говорить, не об "ассинхронной", а об "отложенной" схеме обработки сигнала.

0

Сообщение от g_u_e_s_t Работает оно так: в реальном обработчике сигнал ставиться в очередь (почти как в ОС, но с гарантией, что сигнал не будет потерян), а собственно обработка уже происходит по вызову async_wait(). Т.е. правильнее говорить, не об "ассинхронной", а об "отложенной" схеме обработки сигнала.

Вот я и говорю, что такой вариант ненадёжен.

0

Ну это вы за уши притянули)
С таким же успехом можно впасть в вечный цикл до sigaction() и вместо чтения конфига или чего-то еще тихо помереть)))

0

Сообщение от g_u_e_s_t Ну это вы за уши притянули)

Вовсе не за уши. Вполне себе рабочая ситуация для софтины, которая многими сутками работает без остановок

Сообщение от g_u_e_s_t С таким же успехом можно впасть в вечный цикл до sigaction() и вместо чтения конфига или чего-то еще тихо помереть)))

Есть две разные вещи. Ошибка в процессе обработки сигнала и ошибка где-то в другом месте. Первое у тебя локализовано, второе - размазано по всей программе. Ты один раз обрабатываешь механизм отлова сигнала, сохранение данных и выход из программы и всё. После чего тебе не страшны косяки, которые время от времени появляются в процессе разработки прочих узлов программы. А модуль с обработкой сигнала ты больше не трогаешь

0

Сообщение от Evg Вовсе не за уши. Вполне себе рабочая ситуация для софтины, которая многими сутками работает без остановок Есть две разные вещи. Ошибка в процессе обработки сигнала и ошибка где-то в другом месте. Первое у тебя локализовано, второе - размазано по всей программе. Ты один раз обрабатываешь механизм отлова сигнала, сохранение данных и выход из программы и всё. После чего тебе не страшны косяки, которые время от времени появляются в процессе разработки прочих узлов программы. А модуль с обработкой сигнала ты больше не трогаешь

Простите, но это разговор не о чем.
На мой взгляд ошибка приводящее к не возможности позвать async_wait() или sigaction() для сигнала скажем с SA_RESETHAND вещи одного порядка... и вряд ли вы меня переубедите.

На мой взгляд, все что должен сделать обработчик сигнала, это , а вся реальная работата по обработке должна выполняться в момент когда приложение хочет этого.
Т.е. фактически то же, что реализовано в Boost:asio, но без плясок с очередями (мне они просто не нужны).

0

Сообщение от g_u_e_s_t На мой взгляд ошибка приводящее к не возможности позвать async_wait() или sigaction() для сигнала скажем с SA_RESETHAND вещи одного порядка...

Не одного. Если ты зарегистрировал сигнал через свой механизм отложенной обработки, то обработка запустится только по достижении async_wait. Если ты зарегистрировал сигнал через sigaction, то обработка сигнала запустится независимо от того, в какой позе стоИт твоя программа. sigaction зовётся как правило вначале программы - там же, где в вашем способе зовётся asio::signal_set (насколько я понимаю, это регистрация сигнала). Т.е. "мой способ":

а "ваш" способ:

и слабое место в этой цепочке - это требование "ручками" запустить обработчик сигналов. В "моём" способе обработчик сигналов запустится независимо от моего желания

Сообщение от g_u_e_s_t а вся реальная работата по обработке должна выполняться в момент когда приложение хочет этого

Я и привожу пример, когда такое желание чревато плохими последствиями. Т.е. это не панацея, а выход из ситуации в простых случаях. Изначально речь шла об использовании printf'а внутри обработчика сигнала. Далее был приведён пример с asio, как способ обойти данную проблему. Я в свою очередь привёл пример, когда такой способ оказывается ненадёжным. Я не пытаюсь утверждать, что asio нельзя использовать в принципе, я пытаюсь показать пример, где есть крайняя необходимость обойтись без этого. Желание упростить код похвально, но до тех пор, пока оно не превращается в то, что программист свои заботы перекладывает на пользователя

0

все же так:
Добавлено через 1 минуту

Сообщение от Evg требование "ручками" запустить обработчик сигналов

я же показал, как:
тут еще один плюс в том, что ты можешь по какому-то условию решить, запускать или не запускать ожидание следующего сигнала.

0

Сообщение от niXman все же так

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

Сообщение от niXman тут еще один плюс в том, что ты можешь по какому-то условию решить, запускать или не запускать ожидание следующего сигнала

Если исполнение дойдёт до handler'а.

0

Сообщение от Evg Не одного. Если ты зарегистрировал сигнал через свой механизм отложенной обработки, то обработка запустится только по достижении async_wait. Если ты зарегистрировал сигнал через sigaction, то обработка сигнала запустится независимо от того, в какой позе стоИт твоя программа. sigaction зовётся как правило вначале программы - там же, где в вашем способе зовётся asio::signal_set (насколько я понимаю, это регистрация сигнала). Т.е. "мой способ": C 1 2 3 sigaction ... бесконечный цикл а "ваш" способ: C 1 2 3 4 5 asio::signal_set signals ... бесконечный цикл ... signals.async_wait и слабое место в этой цепочке - это требование "ручками" запустить обработчик сигналов. В "моём" способе обработчик сигналов запустится независимо от моего желания

Я еще раз могу повторить, ваш пример не корректен. Вы совершенно, правильно и верно показываете как делать не надо (boost:asio), но почему-то напрочь отрицаете возможность сделать точно такую же глупость на signal()/sigaction() или ошибиться с sigmask().

Я и привожу пример, когда такое желание чревато плохими последствиями. Т.е. это не панацея, а выход из ситуации в простых случаях. Изначально речь шла об использовании printf'а внутри обработчика сигнала. Далее был приведён пример с asio, как способ обойти данную проблему. Я в свою очередь привёл пример, когда такой способ оказывается ненадёжным. Я не пытаюсь утверждать, что asio нельзя использовать в принципе, я пытаюсь показать пример, где есть крайняя необходимость обойтись без этого. Желание упростить код похвально, но до тех пор, пока оно не превращается в то, что программист свои заботы перекладывает на пользователя

Ну asio тут наверное вообще просто так опоминули в качестве офтопика)
Я согласен с вами, беда asio и других подобных фреймворках напрочь убивают у большинства программистов представление о том "а как же оно на самом деле работает". Но это совсем уже офтопик)))

0

Сообщение от Evg если у тебя этих циклов миллион, то каждый раз около каждого цикла что ли будешь двигать код?

нет.
так:
Добавлено через 2 минуты

Сообщение от g_u_e_s_t беда asio и других подобных фреймворках напрочь убивают у большинства программистов представление о том "а как же оно на самом деле работает".

с этим согласен.
но несколько раз, в разных проектах, писать один и тот же код - нет смысла.
ну понял я как это работает. и хватит. юзаю asio.

0

Сообщение от g_u_e_s_t но почему-то напрочь отрицаете возможность сделать точно такую же глупость на signal()/sigaction() или ошибиться с sigmask()

Я не отрицаю. Я отдельно писал, что эту вещь ты отлаживаешь только один раз. Один раз воткнул в начало main'а инциализацию модуля обработки сигналов, один раз отладил модуль и забыл про это. При дальнейшем внесении ошибки в прочие фрагменты программы (а работать ты будешь только с ними, не трогая обработку сигналов), ты застрахова тем, что обработка сигналов у тебя надёжно работает и в случае зацикливания программы ты данные условно не потеряешь. В варианте с asio надо постоянно заниматься расстановкой точек отложенной обработки, при этом нет никакой гарантии того, что в каком-то цикле ты не застрянешь. А точнее, гарантия есть - если внимательно глазами отслеживать каждый цикл.

Я просто к чему завёл весь этот спор. Мы тут все трое понимаем, о чём идёт речь и понимаем, что надо было бы делать в то или иной ситуации. Но кто-то непонимающий прочтёт про то, что есть такая ацки удобная штука как asio и будет считать, что так оно и надо делать всегда. По типу того, что какой-нибудь автор напишет безапеляционным тоном, что в Си++ надо использовать переменные const вместо макросов, так 9 из 10 человек, прочитавших книгу, начинают орать на каждом повороте, что макросы это для лохов, а тру-программеры пользуются модификаторами const

0