Вопрос по сигналам.

Чем блокировать собрался?

Ну и далеко не все можно заблокировать.

>если в этот момент происходит вызов сигнала (грубо прерывание) и оно заблокировано, забудет ли о нем система, когда программа выйдет из критической секции?

нет.

>Или же после выхода из кр. секции будет сразу же вызван обработчик сигнала?

да.

>И будут ли эти сигналы становиться в очередь?

Не будут. Возможно, существует UNIX-like OS, в которых процесс получит ровно столько сигналов, сколько из было послано, но linux не относится к их числу. Я стараюсь ограничивать себя предположением, что если некий сигнал был послан произвольное [но большее нуля] число раз, то его обработчик будет вызван произвольное [но большее нуля] число раз.

Еще один [вероятно, хорошо известный тебе] момент - SIGKILL заблокировать нельзя.

На сколько я знаю, не блокируется только SIGKILL, тоесть типа kill -9 #### Блокировать планируется SIGINT и SIGTERM. Обработчик уже написан. Все работает, но с блокировкой было бы намного проще и удобней. Блокируется помоему, единственно возможным способом, записью в sa_handler SIG_IGN. И естественно я не собираюсь блокировать SIG_BUS... ;-)

Большое спасибо!

>Я стараюсь ограничивать себя предположением, что если некий сигнал был послан произвольное [но большее нуля] число раз, то его обработчик будет вызван произвольное [но большее нуля] число раз.

уточняю:

если обычный сигнал был послан больше одного раза подряд то он интегрируется и в конечном итоге обработчик будет вызван только *один* раз для каждого типа поступивших сигналов.

существуют также posix real-time signals. так вот эти выстраиваются в очередь если их посылать несколько раз подряд и конечный получатель получит их все а не один общий.

Спасибо! На сколько я понял, эти RT сигналы существуют только в RT Unix-ах, и в Линаксе их нет? Они мне не нужны, но для общего понимания интересно.

>Блокируется помоему, единственно возможным способом, записью в sa_handler SIG_IGN.

по моемому ты чтото не то делаеш.

>и в Линаксе их нет?

есть, иначе смысл про них рассказывать

Хм. В struct sigaction sa; sa.sa_handler = {SIG_DFL; SIG_IGN; Либо указатель на функцию обработчик} Блокировать пока не пробовал, но обработчик свое дело делает исправно.

>>и в Линаксе их нет?

>есть, иначе смысл про них рассказывать

Если можно намекни на хотябы одну функцию, а я уже дальше попробую копнуть?!

> Если можно намекни на хотябы одну функцию, а я уже дальше попробую копнуть?!

http://www.opengroup.org/onlinepubs/009695399/basedefs/signal.h.html

// wbr

думаю здесь только idle поможет

merlin-shadow, а для чего тебе понадобилось организовывать эти "критические секции"? От выключения питания они тебя не спасут, планировщик программу может в любой момент прервать на неопределённое время (в отдельных случаях возможно порядка секунд).. Какая цель у такой критической секции?

man 2 setprocmask

Написал небольшой демон, который считывает Log через pipe, форматит поля, и запихивает все это в postgres. Так вот, я бы нехотел, чтобы он по комманде service мойd stop вышел в момент занесения в базу очередной строки. Т.е. спасать (бороться) надо за каждую стоку log-а. :) Раз уж зашел такой разговор, то есть чайниковский вопрос, как (красиво)сделать, что бы мой демон запускался как демон без &. Были мысли, сделать форк, завершитьродительский процес, а дочку оставить потом как основную, но как-то некрасиво... Да, я тут кое что нашел по RT. И в данном случае, мне это не нужно.

man 2 setprocmask У меня в FC4 такого мана не нашлось.

man 3 daemon

>Так вот, я бы нехотел, чтобы он по комманде service мойd stop вышел в момент занесения в базу очередной строки.

по моемому это надо решать корректной обработкой сигналов а не их запретом

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

если ты не пользуеш read() || write() || select() то вероятность того что ты занимаешся ерундой составляет 100%

Sorry.
man 2 sigprocmask

Да нет, дело не в этом, пример, софтина послала мне строку, я начал ее считывать, считываю почастям стандартными потоками, сразу обрабатываю, теперь происходит прерывание, и все, строка эта если её не запихнуть в базу и не закомитить, потеряется безследно. Это здесь главное. Т.е. речь не идет стабильности работы файловой системы, максимальной производительности (read, write) и т.д.

man 2 sigprocmask Да такая есть спасибо.

BTW, ты в курсе существования syslogd?

Его использование в данном случае приведет к некоторому снижению надежности, но позволит не думать о запуске процесса демоном, да и вообще очень в духе UNIXа.

>софтина послала мне строку, я начал ее считывать, считываю почастям стандартными потоками, сразу обрабатываю, теперь происходит прерывание, и все, строка эта если её не запихнуть в базу и не закомитить, потеряется безследно.

если ты её собственно ручно не выбросиш то никуда она не денется.

>Т.е. речь не идет стабильности работы файловой системы, максимальной производительности (read, write) и т.д.

помоемому ты смешал грешное с праведным

Согласен с cw. Скорее небо упадёт на землю, чем вот так вот "вдруг" придёт SIGTERM. Вообще любая программа, которой требуется подчистить за собой перед выходом (например, завершить транзакцию с БД), устанавливает свой обработчик SIGTERM. Выяснять, как избежать SIGTERM - всё равно что целый вечер выяснять, кто помоет посуду, и в итоге оставить её тараканам на завтрак. Сигналы - это method, not a policy

Что касается SIGKILL, то сие вообще можно трактовать как "электричество кончилось". На этот случай достаточно иметь БД с откатом транзакции, и уж придётся смириться, что "строка лога потеряется". Если потеря такой "строки лога" фатальна для системы.. хороший повод пересмотреть архитектуру последней

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

>Согласен с cw

Не согласен с cw ;).

Не даром при желании корректно остановить некоторый демон ему шлется SIGTERM, потом некоторое время выжидают, чтобы он успел корректно сбросить буфера и завершить свою деятельность, потом при неудаче SIGKILL.

>Да Вы видимо забыли, что речь идет о демоне!!! Т.е. он свою работу сам никогда не заканчивает. Но его бывает нужно об этом попросить... ;) И закончить свою работу он может только при помощи какого-либо сигнала (вероятность 100%! ;)), который я ему пошлю.

ну а какое отношение это имеет к поставленному вопросу????????

>И если я ему пошлю его в тот момент, который я описал выше, и никак не обработаю этот сигнал, то хош-нихош, а данные потеряются...

повторяю ещё раз: данные теряются только в том случае если ты их сознательно или несознательно выбрасываеш. насколько я понял в твоём случае самопроизвольная потеря исключена

info libc/info glibc

повотрорюсь. установка собственного обработчика SIGTERM есть самое обычное и простое решение. _что мешает так поступить?

Хм, я так и сделал, еще до написания сюда сообщения!!! Выше об этом написано :-( Вобщем вопрос прошу считать закрытым. Спасибо Всем!, я выяснил все хотел, и даже больше.