LINUX.ORG.RU

Стекирование обработчиков сигналов

 , , ,


1

2

Какова правильная идеология обработки сигналов?

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

Просто я смотрю на чужой perl'овый код - и вижу, как там $SIG{'HUP'}=sub {} - и мне плакать хочется. И это далеко не только в каких-то примитивных приложениях, в достаточно серьёзных тоже. Особенно напрягает то, что я-то могу сигналы правильно обрабатывать и честно пушить в $sigHndl{'HUP'} обработчики HUP'а. Но в один непрекрасный момент я могу не заметить, как некий чужой модуль возьмёт и сделает $SIG{'HUP'}=... Да, после этого я найду email чувака и насру ему в почту тонну говна, и не успокоюсь, пока не пойму, что чувак понял, насколько он идиот. Но.. Хотелось бы себя обезопасить как-то от таких вещей.

Поэтому номер раз:

Правильно ли я понимаю, что можно запретить модификацию %SIG'а или как-то иначе заблокировать назначение новых обработчиков?

А ещё все мы знаем, что чудес не бывает, хоть они изредка и мироточат, но в целом к чудесам мы относимся с некоторой настороженностью. Так и с обработчиками сигналов: весьма похоже на то, что обработчик сигнала в лучшем случае может быть прерван другим обработчиком (на самом деле нет). А это, в случае использования идеологии «запихни мне обработчиков в стек» - may lead to навсегда зависшее в самом неожиданном месте приложение. Ну, оно же просто обрабатывало... Соответственно,

Номер два:

А верно ли я мыслю, то обработчики сигнала после срабатывания такового сигнала должны:

1) Обрабатываться в асинхронном цикле: поскольку все обработчики в стеке обязаны быть независимы, нас порядок их запуска вообще не колышет;

2) Реальный код каждого обработчика из стека должен тем или иным способом заворачиваться в «блок, который не может выполняться дольше $nTimeout микросекунд» - это ж, небось, про SIG{ALRM}...

Иначе - ну хорошо конечно, когда всё хорошо, но если уж плохо - то совсем плохо, ибо всё стоит колом и никуда не едет.

Ну и последний вопрос: мне вообще стоит писать микро-фреймворк для запуска стека обработчиков при срабатывании сигналов или кто-то уже делал такое - и только я ещё плоды сего архиполезного труда не нагуглил.

Всем заблаговременной гигантской признательности!

P.S. Я слышал про AnyEvent и даже Mojolicious пользуюсь активно. Вопрос в том, что обработчики сигнала там назначаются по принципу «1 сигнал - 1 обработчик». Соответственно, если в действительности в общем случае нужно ~100500 обработчиков, то их нужно вызывать из того одного обработчика, а в этом-то и загвоздка: что именно должен делать он для более-менее гарантированно стабильной работы приложения?

★★★★★

если в действительности в общем случае нужно ~100500 обработчиков

You are doing it wrong.

joy4eg ★★★★★ ()
Ответ на: комментарий от DRVTiny

Если уж так хочется, посмотри в сторону signalfd. И к нему можно прикрутить всякие AnyEvent, тогда ты будешь точно знать что как и где у тебя обрабатывается.

joy4eg ★★★★★ ()

Какова правильная идеология обработки сигналов?

обработчики сигнала там назначаются по принципу «1 сигнал - 1 обработчик»

This.

Обработчик должен запускать какую-то общую процедуру приложения, например «правильное» завершение. Чтобы приложение могло само себя правильно завершать, нужна архитектура, а не наваливание обработчиков из разных мест на один сигнал.

Просто я смотрю на чужой perl'овый код - и вижу, как там $SIG{'HUP'}=sub {} - и мне плакать хочется. И это далеко не только в каких-то примитивных приложениях, в достаточно серьёзных тоже.

Не в серьезности приложения дело. Если такой код в каком-то модуле, предназначенном для повторного использования, то бить по пальцам, в противном случае это совершенно нормально.

annulen ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.