LINUX.ORG.RU
Форум — Development  

блокировка сигнала ?


0

0 

Не подскажите,
Код:

...
sigemptyset(&zeromask); 
sigemptyset(&newmask); 
sigaddset(&newmask,SIGINT);
...
sigprocmask(SIG_BLOCK, &newmask,&oldmask);
tmp_set = read_set;
tmp_time_spec = time_spec;

r_code = pselect(FD_SETSIZE, &tmp_set, NULL,NULL,
                   &tmp_time_spec, &zeromask);
....
//sigprocmask(SIG_SETMASK, &oldmask,NULL);  //? нужна
....
r_code = read(fd, buf, 10);
// если сигнал SIGINT блогирован, то он не будет
// доставляться процессу и не прервет read
// поэтому и вопрос ?
if(r_code == 10) {
   ...
} 
....

После возврата из 'pselect()' маска сигналов процесса
 будет с блокируемым сигналом 'SIGINT' или нет ?
То что pselect() восстанавливает маску сигналов 
процесса я в курсе, но не совсем понимаю,
восстановит как было до вызова sigprocmask() ?

Или нужно после pselect() вставить 
//sigprocmask(SIG_SETMASK, &oldmask,NULL);

Возможно пример глупый, но тем не менее.
anonymous
← java2D & point
On Lisp →

Конечно восстановит. В этом весь смысл pselect.

anonymous
()


http://www.opengroup.org/onlinepubs/009695399/functions/pselect.html

--- cut ---
If sigmask is not a null pointer, then the pselect() function shall replace the signal mask of the caller by the set of signals pointed to by sigmask before examining the descriptors, and shall restore the signal mask of the calling thread before returning.
--- cut ---

-> все восстановится до состояния, которое было до вызова pselect(). с одним но: он восстановит маску вызывающего потока (aka pthread_setmask()) а не процесса целиком. что в принципе вполне логично.

впрочем, если у вас однопоточное приложение то это однохренственно, а если многопоточное, то и смысла в sigprocmask() уже нет.

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda 

Спасибо всем.
проверил с перехватом сигнала SIGALRM.
если мы блокируем сигнал до pselect()
с помощью: "sigprocmask(SIG_BLOCK, &newmask,&oldmask);"
то мы должны разблокировать сигнал после pselect();
с помощью: "sigprocmask(SIG_SETMASK, &oldmask,NULL);"
или : "sigprocmask(SIG_UNBLOCK,&newmask,NULL)"
тогда отрабатывает SIGALRM иначе нет.

Вопрос был так как в примере у Стивенса
"Разработка сетевых приложений" стр.528
разблокировки нет. :(
Меня это сильно озадачило.
Может правда чего не так сделал.

>а если многопоточное, то и смысла в sigprocmask()
>уже нет. 

Почему в многопоточных приложениях нет смысла ?
маска сигналов не может принадлежать потоку ?

anonymous
()
Ответ на: комментарий от anonymous

> Почему в многопоточных приложениях нет смысла ? маска сигналов не может принадлежать потоку ?

маска то потоку конечно принадлежит, но через sigprocmaks() вы меняете маску всего процесса а не заданного потока :)

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda 

Спасибо. 
для потока: pthread_sigmask() ?
 
Вопрос не совсем по этой теме.
POSIX threads как-то можно разрулить ситуацию с приходом
сигнала от ядра SIGINT,SIGIO,SIGALRM,... ?

можно обработать сигнал нужным потоком или понять
какой поток вызвал обработчик ?

anonymous
()
Ответ на: комментарий от anonymous

> Спасибо. для потока: pthread_sigmask() ?

да. описание от POSIX тут:

http://www.opengroup.org/onlinepubs/009695399/functions/pthread_sigmask.html

> Вопрос не совсем по этой теме. POSIX threads как-то можно разрулить ситуацию с приходом сигнала от ядра SIGINT,SIGIO,SIGALRM,... ? можно обработать сигнал нужным потоком или понять какой поток вызвал обработчик ?

AFAIU асинхронные сигналы [генерируемые извне, например, ядром по событию] не могут быть явным образом направлены на обработку в контексте заданного потока [действительно как?]. в отличие от синхронных, [генерируемые через pthread_kill(2)] которые очевидно могут.

как следствие, для асинхронных сигналов ядро выбирает первый попавшийся поток, у которого разрешена обработка заданного сигнала [сигнал разблокирован] и в контексте этого потока его обрабатывает. конкретных правил выбора потока обработки в случае, если есть варианты, POSIX не задает.

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

// wbr

klalafuda ★☆☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← java2D & point
Development
On Lisp →