Делает окно времени, все еще существуют, когда сигнал не заблокирован
[115179] Вы правы, Федора - авангард этого, хотя [115611] freedesktop.org[115612], независимый орган, затем взялся за дело в надежде поощрить его pan-linux. [12145] Согласно [115613] этому [115614], слияние следует шаблону, начатому Solaris, "первичной коммерческой реализацией Unix". Это интересно в том смысле, что оригинальная Unix использовала [115615]/bin[115616], и поэтому избавление от раскола могло означать создание каталогов в [115617]/usr[115618] симлинках вместо обратного.[12146] Однако, учитывая этот вариант, связывание топ-уровней, вероятно, более простое и очевидное.[115184].
2
Gilles 'SO- stop being evil'
21.03.2014, 01:19
Ссылка
1 ответ
[118473] Некоторые ответы на Ваши вопросы зависят от того, как настроен обработчик сигналов. Думаю, мы смотрим на это в контексте настройки обработчиков сигналов через системный вызов [119165]sigaction(2)[119166].[12469]Один из элементов [119167]sigaction структуры[119168] называется "sa_mask". От [119169]man 2 sigaction[119170]:[12470]Похоже, что при правильной настройке даже обрабатываемый сигнал не блокируется. Лично я не могу представить себе применения для этого, но у меня есть печально известное ограниченное воображение.[12471]Так что я бы сказал "да, есть окно между генерацией сигнала и вызовом обработчика сигналов приемных процессов". Итак, другие сигналы могут генерироваться и передаваться в процесс приема. Что касается того, что происходит с этими "другими сигналами": похоже, что сигналы не "стоят в очереди": см. ответ на этот вопрос [119171], [119173], за исключением сигналов "в реальном времени" [119174]. То есть, если ядро получит кучу сигналов [119175]kill(some_pid, SIGHUP)[119176], то в процессе, обозначенном [119177]some_pid[119178], функция обработчика сигналов SIGHUP будет вызвана один раз.[118480].
1
27.01.2020, 22:22
Ссылка