threads & signals

тяжеловатый у человека случай - подружить треды и сигналы.

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

А может тебе вообще надо select-om/poll-om висеть на дескрипторе файла и перечитывать только при изменении??

> в цикле спать на nanosleep

Ха-ха. Бывший паскальщик? За такие методы надо отбирать право пользоваться компилятором.

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

Угу... очень разумно... может книжки почитаешь?

Традиционный подход - все треды блокируют сигналы за исключением
одного треда, который ждет на sigwait() или sigtimedwait().

HTH

>> в цикле спать на nanosleep

>Ха-ха. Бывший паскальщик? За такие методы надо отбирать право пользоваться компилятором.

если ты знаеш толк в извращениях с sigalrm в тредах то не думай что здесь все такие.

>Угу... очень разумно... может книжки почитаешь?

>Традиционный подход - все треды блокируют сигналы за исключением одного треда, который ждет на sigwait() или sigtimedwait().

или pause().

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

и ещё надеюсь ты знаеш о существовании кривых libc окромя glibc?

Ладно, я не очень силен в тредах и сигналах, но то приложение, которые я написал, корректно работает с потоками. Я вполне могу создать отдельный поток, который будет заниматься этим делом. Если так лучше сделать - то как лучше усыпить поток но некоторый период времени? Т.е. лучше сделать как предлагалось выше - все потоки игноярт сигнал, а один обрабатывает sigalarm и пока его жедт вызывает pause() ? А если другой поток (который заблокировал прием сигналов) висит в это время на poll(), на его это никак не повлияет ?

>Я вполне могу создать отдельный поток, который будет заниматься этим делом.

и не изобретать варианты. в конкретном случае от них не будет никакой пользы.

>Если так лучше сделать - то как лучше усыпить поток но некоторый период времени? Т.е. лучше сделать как предлагалось выше - все потоки игноярт сигнал, а один обрабатывает sigalarm и пока его жедт вызывает pause() ?

если ты уверен что sigalrm больше никому не понадобится то так и сделай

>А если другой поток (который заблокировал прием сигналов) висит в это время на poll(), на его это никак не повлияет ?

никак

Ok, спасибо за помощь

> Ладно, я не очень силен в тредах и сигналах...

Стой-стой, причем тут pause() ?

Смотри:

1. До создания тредов делаешь pthread_sigmask(SIG_BLOCK, &signal_set, NULL)
блокируя все сигналы. Создавамые позднее треды унаследуют эту маску.

2. В каком-либо треде (да хоть в main thread) крутишь в цикле
sigwait(&signal_set, &sig), где signal_set содержит интересующие тебя
сигналы. Как тока сигнал поступает - sigwait() выходит, сохраняя номер
сигнала в sig и ты его обрабатываешь. Не надо никакого pause().
Да, AFAIK можно сделать несколько тредов - обработчиков сигналов при
условии, что они ждут в своих signal_set непересекающиеся множества
сигналов.

HTH

>sigwait(&signal_set, &sig)

с какой версии ядра поддерживается эта штука?

> > sigwait(&signal_set, &sig)

> с какой версии ядра поддерживается эта штука?

Не знаю но вроде она была еще в LinuxThreads,
естественно испытывая все связанные с этим проблемы.
Короче man sigwait.
BTW есть еще sigsuspend(), чем-то похожий по смыслу.

HTH