Вариант использования - необходимость замаскировать SIGPIPE в pthreads, которые выполняют свои собственные write() и / или SSL_write(), и скомпилировать его в текущих системах POSIX-i sh, таких как Linux, macOS, BSD, et c. Типичный подход к Linux довольно хорошо объяснен здесь , и есть много хороших дополнительных обсуждений по topi c здесь .
Типичный signal(SIGPIPE, SIG_IGN) работает везде, где я пробовал, но (я считаю) должно быть более хирургическое решение, которое позволяет избежать глобального игнорирования SIGPIPE. Также было бы неплохо по возможности избегать прагмы c, указывающей платформу.
Функция sigtimedwait() не существует в (текущих?) Версиях macOS, поэтому кроссплатформенное решение маловероятно используя этот подход.
Кажется, что функция sigwait() существует повсюду, но она заблокируется навсегда, если конкретный сигнал фактически не ожидает обработки. Таким образом, следующий лучший подход, по-видимому, состоит в использовании sigpending(), чтобы увидеть, что ожидает выполнения, а затем sigwait() для его обслуживания, которые кажутся доступными.
Меня беспокоит то, что фактически существует ничего (что я могу найти) не написано по этой конкретной проблеме, что обычно является признаком того, что я упускаю что-то до боли очевидное.
Итак, pthread_sigmask() / sigpending() / sigwait() / pthread_sigmask() хороший выбор для вышеуказанного варианта использования? Или есть (не?) Очевидные подводные камни, о которых я должен знать?