Возврат из обработчика сигнала и оставление сигнала в маске - PullRequest
Новая
       20

Возврат из обработчика сигнала и оставление сигнала в маске

3 голосов
/ 03 апреля 2011

У меня есть ситуация, когда обработчик сигнала должен при определенных условиях вернуть без снятия маскировки с себя , т.е. после возврата сигнал должен оставаться заблокированным в маске сигнала потока.Прыжок из обработчика сигнала с longjmp не будет работать, потому что мне нужно вернуться к точной точке, которая была прервана, как нормальный возврат обработчика сигнала.Есть ли какой-либо совместимый способ сделать это, кроме использования ucontext_t, который был удален из стандартов?Я не могу изменить обработчики сигналов или расположение;все эффекты должны быть локальными для потока.

Цель этого кода связана с некоторыми атомарными операциями и возможностью возникновения состояния гонки или тупика.В основном потенциально прерванный код выглядит следующим образом: 

atomic_write(&thread_local_flag, 1);
atomic_dec(&global_counter);

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

Если бы я мог оставить сигнал заблокированным, когда обработчик сигнала вернется, проблем не будет.

1 Ответ

0 голосов
/ 03 апреля 2011

Хм, лучшее, что я нашел на данный момент ... Кажется, это работает и не зависит ни от каких ucontext функций, только от структуры, которая не была удалена. В обработчике сигнала: 

if (thread_local_flag) {
    sigaddset(&((ucontext_t *)ctx)->uc_sigmask, sig);
    return;
}

Здесь sig и ctx - первый и третий аргумент обработчика сигнала типа SA_SIGINFO соответственно.

Есть мысли о том, является ли это правильным использованием или ужасным хаком (или и тем, и другим)?

...