Обработка сигналов - асинхронные функции и многопоточные приложения, стек сигналов - PullRequest
3 голосов
/ 05 марта 2012

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

Ответы [ 2 ]

2 голосов
/ 05 марта 2012

Когда процесс получает сигнал, он обрабатывается в контексте процесса.Вы должны использовать только функции, защищенные от дежурного режима или входящие функции из обработчика сигнала.Например, вы не можете вызвать malloc () или printf () в обработчике сигналов.Причина:

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

*) Другая возможность, если блокировка кучи была получена вашим процессом, когда он получил сигнали затем вы вызываете malloc () из вашего обработчика сигнала, он видит, что блокировка удерживается, и бесконечно ждет получения блокировки (бесконечно, потому что поток, который может снять блокировку, не будет работать, пока сигнал не будет полностью обработан).

2) Сигналы запускаются в контексте процесса.Что касается стека сигналов, вы можете посмотреть на этот ответ SO -> Есть ли у держателей сигналов отдельный стек?

3) Что касается получения нескольких экземпляров одного и того же сигнала, вы можете посмотреть на этоlink -> Обработка сигналов в UNIX , где Rumple Stiltskin хорошо на него отвечает.

0 голосов
/ 05 марта 2012

Я знаю немного соляриса. Так что я использую это для деталей. LWP == Solaris для "потока", как в pthreads.

сигналы прерывания, такие как SIGILL, доставляются в поток, вызвавший прерывание. Асинхронные сигналы доставляются в первый активный поток (LWP) или процесс, который не блокирует этот сигнал. Модуль ядра aslwp () обходит таблицу заголовков процесса (имеет связанные LWP), ища первого вероятного кандидата для получения асинхронного сигнала.

В ядре находится стек сигналов. Я не уверен, что / как ответить на ваш вопрос стека сигналов. Один процесс может иметь несколько ожидающих сигналов. Это то, что вы имеете в виду?

Каждый сигнал, предназначенный для процесса, удерживается там до тех пор, пока процесс не переключит контекст (или не будет принудительно) в активное состояние. Это отчасти потому, что вы, как правило, не можете подвергнуться ловушке, когда контекст процесса был заменен, а процесс ничего не делает в процессе обработки. Вы, конечно, можете подвергаться асинхронным сигналам. Но процесс не может «делать что-либо» с любым сигналом, если он не может работать. Итак, в этот момент ядро ​​переключает контекст обратно на активный, и сигнал доставляется через aslwp ().

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

Попробуйте прочитать это:

developers.sun.com/solaris/articles/signalprimer.html
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...