Темы, сигналы и обработка детей: какой мир ... какой мир - PullRequest
Новая
       0

Темы, сигналы и обработка детей: какой мир ... какой мир

6 голосов
/ 15 ноября 2011

Так что у меня есть интересная проблема дизайна.Я работаю на SLES 9+ Linux, ядре 2.6+ и имею многопоточное приложение, выступающее в качестве RPC-клиента.Идея состоит в том, чтобы иметь несколько потоков для обработки запросов;Один такой запрос - запустить «задание» как дочерний процесс.

Теперь у меня проблема с настройкой правильного обработчика сигналов для работы с различными сигналами.Что я сделал, так это настроил еще один поток для обработки сигналов, находясь в состоянии sigwait(), в то же время блокируя все соответствующие сигналы в других потоках.Идея состоит в том, что все сигналы для процесса должны быть доставлены потоку обработки сигналов, а остальные потоки должны беспокоиться только об обработке запросов по мере их поступления.

Все это прекрасно работает, за исключением тех гнилых детейЯ всегда бросаю своих фрисби на заднем дворе и топчу по всему газону ... но, если серьезно, моя нить обработки сигналов не получает сигнал SIGCHLD.Мое лучшее предположение относительно того, что здесь происходит, заключается в том, что, поскольку поток обработки сигналов не является потоком, который породил дочерний элемент, это будет не поток, который получает SIGCHLD, а вместо этого мои рабочие потоки, которые это сделали.

Итак, что касается моих вопросов:

  1. Я без ума от того, что SIGCHLD не доходит до моего потока обработчика сигналов?
  2. Если я не сумасшедший (это натянутоЯ знаю), как бы вы решили эту маленькую проблему?В настоящее время я занимаюсь настройкой очень простого обработчика сигнала для SIGCHLD, установленного во всех потоках, который просто передает сигнал в виде сигнала SIGUSR2 группе процессов, которая блокируется во всех потоках, что позволяет потоку обработки сигналов.Это , кажется, работает, однако я не могу не думать, что либо я что-то упустил, либо есть лучший способ обработать это ... хе-хе, получить это, ручка это ... хорошо, я сейчас остановлюсь

As per David Schwartz request SLES9: NPTL 2.3.5, SLES10: NPTL2.4

Ответы [ 2 ]

2 голосов
/ 15 ноября 2011

(Изменить: потому что я не могу читать, и вы уже делаете правильные вызовы pthread_sigmask ....)

В ядре 2.6, когда для SIGCHLD задано игнорирование / SIG_IGN, ядро ​​будет пожинать дочерние процессыдля тебя.Похоже, если вы настроили специальный обработчик для SIGCHLD для своего потока обработки сигналов, чтобы избежать установки SIGCHLD в SIG_IGN / SIG_DFL.

Редактировать (из комментариев): Я думаю, что вы столкнулись с крайним случаем.Если вы оставите его как SIG_IGN в потоке, порождающем дочерние элементы, ядро ​​даже не отправит SIGCHLD.Но если вы установите его для обработки, то вместо этого вызывается ваш обработчик.Я думаю, что если вы установите обработчик, но все равно заблокируете сигнал в pthread_sigmask, сигнал будет доставлен потоку, у которого сигнал не заблокирован (ваш поток sigwait).

1 голос
/ 15 ноября 2011

Скомпилируйте и запустите этот код с примерно теми же параметрами компиляции, которые вы используете для сборки своей программы: 

#include <pthread.h>
#include <stdio.h>
#include <unistd.h>
int main(void)
{
    char buf[512];
    confstr(_CS_GNU_LIBPTHREAD_VERSION, buf, 500);
    printf("%s\n", buf);
}

В этом объявлении не совсем ясно, поставляется ли NPTL с SLES 9и, если это так, если это по умолчанию.Но я уверен, что вы используете LinuxThreads, у которого нет возможности направлять сигнал процессу.

...