Отправляет ли setimimer ITIMER_PROF (SIGPROF) каждому потоку в многопоточности и NPTL и Linux (2.6.21.7)?

Question

В руководстве сказано, что setitimer является общим для всего ПРОЦЕССА, и SIGPROF отправляется ПРОЦЕССУ не в поток.

Но когда я создаю таймер в моем многопоточном ПРОЦЕССЕ, если я не создаю независимые стеки дляВ каждом потоке в PROCESS для обработки signo я получаю очень серьезные ошибки в обработчике sig.Через некоторую отладку я подтверждаю, что стек (единственный случай стека) должен был быть повторно введен.

Так что теперь я подозреваю, что SIGPROF могут быть отправлены в многопоточность одновременно?Спасибо!

Answer 1

Я не слежу за подробностями вашего вопроса, но общий случай таков:

Может быть сгенерирован (и, следовательно, ожидается) сигнал для процесса в целом (например, при отправке с использованиемkill (2)) или для определенного потока (например, определенные сигналы, такие как SIGSEGV и SIGFPE, сгенерированные как следствие выполнения конкретной инструкции на машинном языке, ориентированы на поток, как и сигналы, нацеленные на конкретный поток с использованием pthread_kill (3)). Сигнал, ориентированный на процесс, может быть доставлен любому из потоков, для которого в данный момент сигнал не заблокирован.Если более одного из потоков имеет разблокированный сигнал, то ядро ​​выбирает произвольный поток для доставки сигнала.

сигнал man (7)

Вы можете заблокировать сигнал для определенных потоков с помощью pthread_sigmask и, исключив его, направить его в поток, который вы хотите обработать.

Answer 2

Согласно POSIX, альтернативный стек сигналов, установленный с sigaltstack, является для каждого потока, и не наследуется новыми потоками. Однако я считаю, что в некоторых версиях кода библиотеки pthread в Linux и / или в пользовательском пространстве (по крайней мере, в старых ядрах с LinuxThreads и, может быть, в некоторых версиях с NPTL?) Есть ошибка, при которой альтернативный стек наследуется, и, конечно, это приведет к сбою всякий раз, когда Вы используете альтернативный стек. Есть ли причина, по которой вам нужны альтернативные стеки? Обычно единственная цель состоит в том, чтобы обрабатывать переполнения стека полуградиционно (позволяя себе некоторое место в стеке, чтобы перехватить SIGSEGV и сохранить все несохраненные данные перед выходом). Я бы просто отключил его.

Либо используйте pthread_sigmask, чтобы заблокировать SIGPROF во всех потоках, кроме основного. Обратите внимание, что во избежание неприятного состояния гонки здесь вам необходимо заблокировать его в главном потоке перед вызовом pthread_create, чтобы новый поток начинался с блокировки, и разблокировать его после возврата pthread_create.