[sisyphus] Q: Очень непростой вопрос на тему select() и сигналов

[Michael Pozhidaev <msp@altlinux.ru>]

Привет всем!

Вопрос для мастеров тщательной обработки сигналов. Если у кого-нибудь
есть опыт, дайте рекомендации, пожалуйста.

Предположим, мне надо написать программу с обработкой SIGCHLD и данных
поступающих от разных файловых дескрипторов. Хочу сделать это тщательно
и продуманно. Оговорка: есть действия, которые должны быть выполнены
_*незамедлительно*_ после получения SIGCHLD. "Незамедлительно " имеется
в виду без заметной задержки пользователю. Допускается задержка 0.1-0.2
секунды.

Схематически код выглядит так:

int there_was_sigchld = 0;
void sigchld_handler(int)
{
there_was_sigchld = 1;
}

void check_sigchld()
{
if (there_was_sigchld)
do_what_we_need();
there_was_sigchld = 0;
}

void main_loop()
{
while(1)
{
check_sigchld();
select(required_fds);
check_data_from_fds_if_there_was_any();
}
}

Всё выглядит как будто бы нормально: select() просыпается всегда, как
только приходит сигнал или появляются данные в дескрипторах. Мы не уснём
на select() с непроверенным флагом получения SIGCHLD, а когда получим
его ещё раз, то проснёмся.

НО! Если сигнал придёт ПОСЛЕ вызова check_sigchld(), но ДО вызова
select() (вероятность ничтожная, но всё же), то действия, требуемые при
получении SIGCHLD окажутся выполненными только после того, как придут
очередные данные по дескрипторам, а это может быть долго и нас не
устраивает.
Читаем внимательно ман по select(), там есть интересное место:

--- начало цитаты ---
       Идея pselect в том, что если нужно подождать события: сигнала или активности  на
       файловом  дескрипторе, то требуется атомарная проверка, чтобы предотвратить race
       condition.  (Предположим, обработчик сигнала  устанавливает  глобальный  флаг  и
       возвращает  управление.   Тогда  проверка  этого  глобального  флага, за которой
       следует select(), может привести к  подвисанию,  если  сигнал  появляется  сразу
       после  проверки,  но  прямо  перед  вызовом  select.   С другой стороны, pselect
       позволяет сначала заблокировать сигналы, обработать пришедшие сигналы,  а  затем
       вызвать  pselect()  с  желаемой sigmask, тем самым избегая race condition.)  Так
       как Linux в настоящее время не содержит  системного  вызова  pselect(),  текущая
       реализация этой процедуры в glibc все еще содержит race condition.

--- конец цитаты ---

Почти наш случай. Вот тут и нужен совет: правильно я понимаю, что должно
быть так:

void main_loop()
{
while(1)
{
block_sigchld();
check_sigchld();
pselect(required_fds, and_signal_mask_with_enabled_sigchld);
check_data_from_fds_if_there_was_any();
}
}

Если должно быть так, то что произойдёт, если sigchld пришёл в тот
краткий момент, когда он был заблокирован? pselect() увидит, что пока
сигнал был заблокирован, он приходил, и нужно сразу прекратить ожидание,
вызвать его обработчик и дать программе его обработать? Если нет, то
тогда мы вообще теряем получение SIGCHLD. Ещё есть интересная функция
sigpending(), но уместна ли она здесь, вот это непонятно. 

Очень прошу совета и помощи. :) Придумать test case на этот случай почти
невозможно, т. к. нужно умудриться получить SIGCHDL в совершенно
невероятный момент.
-- 
Michael Pozhidaev. E-mail: msp@altlinux.ru.
Tomsk State University. http://www.csd.tsu.ru
ALT Linux Team. http://www.altlinux.org