В целом, это хорошая идея, чтобы скрыть поля за свойствами, даже если вы «точно знаете», что не будете переопределять поле. Слишком часто то, что вы «наверняка знаете» сегодня, меняется завтра. А создание свойства для ссылки на поле - это небольшая проблема.
Тем не менее, статические анализаторы не могут заменить мысли. Если вы довольны своим дизайном и, по вашему мнению, анализатор ошибочен, игнорируйте или (если возможно) подавляйте это предупреждение в таких обстоятельствах.
Это то, что я обычно делаю в основном потоке приложения:
/* before starting other threads */
sigset_t sigs;
sigemptyset( &sigs );
sigaddset( &sigs, SIGTERM );
sigaddset( &sigs, SIGINT );
/* add other signals to handle */
if ( pthread_sigmask( SIG_BLOCK, &sigs, 0 )) { /* handle error */ }
/* can start threads now */
...
/* in the main event loop */
siginfo_t info;
if ( sigwaitinfo( &sigs, &info ) == -1 ) { /* handle error */ }
switch( info.si_signo )
{
case SIGTERM:
case SIGINT: /* raise shutdown event */ break;
default: /* other actions - log rotation, etc. */
}
...
Таким образом, сигналы становятся обычными событиями приложения - никаких особых ограничений контекста сигналов и т. Д.
Ожидание также может быть выполнено с таймаутом через sigtimedwait
, хотя производные BSD не поддерживают это.
Мне кажется, что вам нужна переменная условия pthread, чтобы вы могли разбудить любое количество нескольких потоков, вызвав одно «событие» из вашего главного потока.
См. справочные страницы для PTHREAD_COND_DESTROY и PTHREAD_COND_BROADCAST для получения дополнительной информации.
Кажется, ваш план в порядке. Вы заставляете один поток обрабатывать системные сигналы. Вам нужно будет замаскировать сигналы, за исключением некоторого-другого-сигнала в ваших рабочих потоках, с помощью pthread-sigmask ().
Я бы предпочел использовать отдельный поток для обработки сигнала процесса, а не мастер. Пусть он вечно ждет семафор или sigwait () или что-то еще, ожидая запуска обработчика сигнала. Уберите код pthread-kill из обработчика сигнала. Просто установите переключатель, и пусть ожидающий сигнал поток отправит другой_сигнал рабочим потокам и завершится сам.