Является ли fork (должен быть) безопасным от обработчиков сигналов в многопоточной программе?

Я действительно не уверен в требованиях, которые POSIX предъявляет к безопасности fork при наличии потоки и сигналы. fork указан как одна из функций, защищенных от асинхронных сигналов, но если есть вероятность, что код библиотеки зарегистрировал обработчики pthread_atfork , которые не являются безопасными для асинхронных сигналов, делает это отрицать безопасность вилки ? Зависит ли ответ от того, может ли поток, в котором запущен обработчик сигналов, использовать ресурс, который нужен обработчикам atfork? Или сказал иначе, если обработчики atfork используют ресурсы синхронизации (мьютексы и т. д.), но fork вызывается из обработчика сигналов, который выполняется в потоке, который никогда не обращается к этим ресурсам, соответствует ли программа?

Building по этому вопросу, если "потокобезопасный" разветвление реализовано внутри системной библиотеки с использованием идиом, предложенных pthread_atfork (получить все блокировки в обработчике предварительной вилки и снять все блокировки как в родительском, так и в дочернем обработчиках постфорка ), тогда безопасно ли использовать fork из обработчиков сигналов в многопоточной программе? Разве это не возможно, чтобы поток, обрабатывающий сигнал, мог находиться в середине вызова malloc или fopen / fclose и удерживать глобальную блокировку, что приводит к взаимоблокировке во время fork ?

Наконец, даже если fork безопасен в обработчиках сигналов, безопасно ли fork в обработчике сигналов, а затем вернуть из обработчика сигнала, или вызов fork в обработчике сигнала всегда требует последующего вызова _exit или одной из функций семейства exec перед обработчик сигнала возвращает?